Here, you turn to the skill sets that you and your Intranet team will need. Most of these skills are directly related to Web matters-server administration, CGI script programming, and the like-but others are routine, computer system administration skills. As your Intranet develops into a mission-critical system for your organization, both sets of skills become crucial.
Part II, "Getting Set Up on the Server," gives you a good deal of information on Web server setup, but you'll eventually want to consult a more detailed reference. One such book is Web Site Construction Kit for Windows NT by Christopher Brown and me (ISBN 1-57521-047-9), published by Sams.net.
Obviously, the very first set of people skills you need are those encompassing basic Web server setup and administration. This set of skills is also probably the single most important one to the success of your Intranet. I'm referring to the areas of content design, document conversion, security control, and even CGI programming.
Your choice of a model for the administration of your Intranet (see the discussion of these models in Chapter 2, "Planning an Intranet") has important corollary choices, most importantly with respect to your need for a Webmaster. The Webmaster is the person with overall responsibility for setting up and maintaining your Web server(s). If you choose the centralized or mixed model, your Webmaster is the most critical part of your Web. Although many organizations add Webserver administration to the responsibilities of existing staff, a growing number of companies are creating dedicated positions. In fact, Webmastering skills are in high demand, with salaries to match. A recent survey of Webmasters in Fortune 500 companies by Web Week magazine showed a full two-thirds of corporate Webmasters earning more than $45,000, and nearly 40 percent with salaries over $65,000, reflecting the value companies place on their skills.
However you assign responsibilities in this area, it's vital that you recognize the value of your Webmaster(s) and ensure he has the skills he needs. This might seem to contradict earlier statements about the relative ease of basic Web server setup and the simplicity of HTML. In fact, although it's true you can set up a simple Web server on a pc using point-and-click methods and have it running in a few minutes, setup and administration of a major Web server, with fill-in forms, CGI scripts, Java applets, appropriate security, and all the other extras you and your customers will want added is considerably more involved and requires additional skills. Just as you shouldn't skimp on the hardware to run your Web server, don't expect to save money in the long run by throwing an inexperienced staffer into the job of setting up and running a major Web server. Because your Webmaster is such a vital cog in your Intranet, we'll devote a good deal of attention to the skills he or she needs.
If you're unsure where to look for your Webmaster, experienced system administrators make good choices for Webmasters because they already have many of the needed skills. You might have potential Webmasters in your MIS department. There are few experienced system administrators who don't already have these skills and knowledge, even if they've never set up a Web server-an increasingly rare situation, with the rapid growth of the Web. It can't be overemphasized that many of the most useful and important details of Web server setup are less than obvious to people who are used to installing software by double-clicking a:\setup in Microsoft Windows Explorer (or File Manager). Proper system administration of a network is part science and part art. The accumulated experience and intuition of a good system administrator can keep your Web server in top shape, tuning the performance of the server and ensuring the system is available "24-7." If your Intranet becomes mission critical, you'll want a seasoned Webmaster running it.
Look at some of the most critical skills your Webmaster will need. I'm assuming here that your Web server will be running Windows NT (and perhaps BackOffice), of course.
Although most Web servers come with default settings for many operational details, your Webmaster needs a good understanding of what they mean, how they might be changed, and what effects changes may have. For example, does your Web administration model allow for user accounts on the system running your Web server? If so, will you allow these users to create their own HTML documents to be served or disable the default feature of the server software that allows it? Further, if you allow users to create CGI scripts in their home directory area, it's critical that your Webmaster understand what the scripts do and educate users on the security aspects of CGI. There are a number of other details of Web server setup that need to be understood, most of which require a thorough grounding in Windows NT system administration. These include
You'll probably want to consult more detailed references on Web server setup and administration. A good place to start is the documentation that comes with the server software.
Creation of effective and safe CGI scripts (see Chapter 10,
"Intranet Security in Windows NT") requires not only
programming skills but also a fundamental understanding of NT
User Administration, the Web's Hypertext Transfer Protocol (HTTP),
and TCP/IP in general. Recall from Chapter 3,
"The Software Tools to Build a Web," that the CGI mechanism
works by taking the information entered in Web fill-in forms and
passing it as standard input to a back-end script
for processing. When finished, the back-end script returns the
results of its run as standard output, usually in the form
of HTML markup, which can be interpreted and displayed
by the user's Web browser software. I'll defer the comparison
of the CGI process with the ISAPI method until Chapter 19,
but suffice it to say, the two are similar.
| Note |
CGI programs are also called CGI scripts or applications. The reason they are called scripts is that they can be written in Perl or the UNIX command shell, in which case they are interpreted rather than compiled, and the Web has a strong background in UNIX. When the C language or Visual Basic is used for CGI, the terms CGI program or CGI application are preferred to CGI script. Even simpler, some people just refer to all such things as CGIs. |
Simple C GI scripts might use only a couple of pieces of information, such as a simple text string for which to search and a list of files in which to search for it. More complex ones, however, might throw around a long list of input data, requiring elaborate variable handling, use of data arrays, and use of underlying operating system calls. Further, you'll want to validate data entered by users before processing it. You'll probably not be able to manage such complex scripts except in a full-feature programming language like C or Perl. Experienced system administrators already have a working knowledge of these languages, and this experience is easily portable to CGI programming. Perl is widely used for CGI scripting because of its power (including access to operating system calls), portability, and relative ease of use.
Whether you use Perl, C, or some other programming language for your CGI scripts, you need to be concerned about the security aspects of the scripts. Although you're less likely to have efforts to break the security of your Web server if your server is not on the Internet, there are still good reasons to follow good security practices. Programming languages like Perl and C include access to underlying operating system resources, including the ability to access, read, and manipulate memory and files. At the very least, you need to make sure your scripts don't inadvertently overwrite important files on your system or create memory buffer overflows when users enter incorrect information in Web fill-in forms. Curious, or in the extreme, malicious users might enter harmful system commands in Web forms; your CGI scripts need to validate the data that's entered to make sure nothing but appropriate data gets executed on the server. Even simple typographical errors are potential problems if data isn't validated. These security considerations, of course, are even more important if your Web server is accessible on the Internet.
If you are training to be a Webmaster and you want more information about Perl or C, you might want to get David Till's book, Teach Yourself Perl in 21 Days (ISBN 0-672-30586-0), also published by Sams.net. Sams also has a wide range of reference books on other programming languages such as Teach Yourself C Programming in 21 Days, Premier Edition, by Peter Aitken and Brad Jones (ISBN 0-672-30736-7).
By running your Intranet Web server on Windows NT, you'll find several choices for your CGI scripting. In addition to Perl and C, it's possible to use Visual Basic, particularly if your Web server supports WinCGI. WinCGI was developed by Bob Denny to make CGI scripting more accessible to the masses in the Web site server from O'Reilly. As another alternative, Web Site Construction Kit for Windows NT provides details about how you can take advantage of VB and its ease of building a database interface through ODBC (see Chapter 16 for more information about ODBC databases), in cooperation with a standard C program which performs the CGI tasks.
Java applets are a little harder to identify because they have characteristics in common with CGI scripts, HTML documents, and Web browser helper applications. Like CGI scripts, applets are computer programs that run on the user's computer, not on the Web server. Like HTML documents, Java applets are first downloaded from a Web server by clicking a hyperlink. The client machine runs the applet and then discards it from memory when done. (It stays on the local hard disk to avoid repetitive downloading in case the same programs are needed again.) Helper applications, on the other hand, are programs that already exist on the user's computer and are run when data for the application is downloaded from a Web server.
Java is a completely new programming language, something like C++ in that it's object-oriented. As you might guess, it's hardware and operating-system independent. Java applets run on any computer system with a Java viewer or Java-compatible Web browser. Many of the standard features of high-level programming languages have purposely not been implemented in Java for both efficiency and security reasons. For instance, Java can't access or manipulate memory registers.
Security experts remain skeptical about the whole idea of running unknown programs in a Web browser on a corporate LAN, or even on a stand-alone pc. Remember, Java programs are automatically downloaded from sources over which a system administrator has no control. You are not being paranoid if you think this is more than a little scary, assurances about Java's built-in security features notwithstanding. Although Java applets are considered immune from external virus infection, this issue should not be taken for granted.
There is much new ground to be explored with Java for both possibilities and risks. You'll likely need to learn Java programming if you intend to use it on your Intranet, unless you know how to find ready-made code that accomplishes the task you have in mind. Moreover, you'll want to be intimately familiar with its possible security implications for your customers. For SunSoft's view on Java, along with extensive documentation, copies of the HotJava Web browser, and demonstration Java applets, access the Java home page (shown in Figure 4.1) at http://java.sun.com/. Also, Netscape has Java demos at http://home.netscape.com/comprod/products/navigator/version2_0/java_applets/index.html.
Figure 4.1: The Sun Java Home Page is a virtual playground for Java lovers.
Even if your Intranet is completely isolated from the Internet, and even if you trust all of your customers, it's still a good idea to manage your Web server(s) with routine security. If you do make your Web server(s) accessible on the Internet, doing so becomes critical. Web server software like the IIS or Purveyor packages have built-in security. To take full advantage of it you need to understand the details of server security and the NT User Manager for Domains.
As noted above, because CGI scripts run on your Web server, it's critical you make sure there are no possibilities for them to compromise the server's security through inappropriate data being passed to them by malicious users. Just like you should inspect any other software you may retrieve from the Internet or some BBS before running it, make sure any CGI scripts you may download are secure. You can only do this by inspecting and understanding the scripts' code. In practice, this means you must understand Perl because it is frequently the language of choice for CGI programming.
Your customers will likely demand to use fill-in forms on your Intranet; some of them might even want to write their own CGI scripts and/or obtain them from others. One of your security-related decisions is that of restricting CGI scripts to your server's protected filesystem or allowing users' CGI scripts to run out of their own home directories. Choosing the latter means you need to inspect the user scripts for security implications. This doesn't mean you don't trust your customers who just want to get their work done, which is the object, after all, of your Intranet. It does mean you can't necessarily expect customers to be attuned to the potential for intentional (or unintentional) misuse of CGI scripts and their security aspects. You'll want to inspect customer CGI scripts to make sure they're appropriately secure and counsel users on them.
The security of your Web server is also impacted by the administrative decisions you make with respect to managing your Web. Although it's clear in the centralized model that only authorized people can place Web documents and CGI scripts on your server, and you can take the necessary practical and management steps to enforce this policy, this is less clear in the other models.
Finally, your Web server is only as secure as the computer on which it's running. All the security precautions in the world are worth nothing if everyone in the office has the administrator password to your server, or if you haven't closed well-known security holes in the system. System and network security are meat and potatoes to experienced NT System Administrators, and security considerations alone present a strong argument for your Webmaster to have an extensive background in system administration. These considerations are especially important if your organization is connected to the Internet. The overall security of your network should be secured by a firewall system of some kind, and you should carefully configure the access-control features of your Web server(s) to limit access to authorized users.
By the way, the best NT System Administrators are often certified
through rigorous testing by Microsoft. Individuals who can pass
the test are given the badge of honor MCSE (Microsoft Certified
Systems Engineer). In addition to NT configuration, MCSEs are
usually skilled in at least one other technical product, such
as SQL Server.
| Note |
As the word implies, a firewall system isolates your network from the Internet, limiting access between the two networks. Usually, firewalls are set up to permit certain Internet services, such as e-mail, to enter your network but block other services that might be insecure or subject to abuse. Firewalls can also be used to selectively permit access by users in an organization to outside Internet services, such as FTP or World Wide Web servers. For more information on Internet firewalls, see Internet Firewalls and Network Security, by Karanjit Siyan and Chris Hare (ISBN 1-56205-437-6), published by New Riders. Many commercial firewall vendors have Web pages, including Raptor Systems (http://www.raptor.com/), which has just ported its Eagle product line to Windows NT, Trusted Information Systems (http://www.tis.com/), with its Gauntlet product line, and others. For general firewall information, including access to the home pages of a long list of firewall and security vendors, see the Firewall Product Developers Consortium Web page, maintained by the National Computer Security Association, at http://www.ncsa.com/fwpdmem1.html. The ncSA (not to be confused with the National Center for Supercomputing Applications, makers of ncSA Mosaic and the ncSA httpd server) has a home page (see Figure 4.2) with useful security information at http://www.ncsa.com/. |
Here are a few more people skills you'll have to bring up with your Intranet team. Leaving a pc Web server running unattended in a non-secure area is an invitation to both the malicious and the curious: You might as well forget any security on that server.
Viewer security is also a potential problem. Although you might implement access control on your Web server (which will limit user access to all or part of your Web server by specific TCP/IP addresses or by password), remember that an unattended pc that is already viewing protected documents is not secure. Let's say you plan to restrict access to certain confidential personnel information to management. You'll need to counsel management users in these security issues. For example, leaving one's desk for coffee while viewing confidential information without starting up a screen lock or taking some other security measure defeats all the Web server access controls.
A final, catch-all set of Webmaster skills is the overall administration of your Web server system. These skills range from everyday backups of the system to performance tuning to disk-space and user account management. Although routine in some respects, the performance of these duties is a critical factor in the care and feeding of your Intranet. Even if you have hardware and software maintenance/support contracts with outside vendors, there's no substitute for the experience and intuition of a System Administrator when problems arise. Provided your System Administrator follows good backup practices, for example, restoring lost or erroneously deleted files can take just a few minutes. Webmasters and System Administrators are also important in the training of your customers in the use of your Web.
There are dozens of third-party training firms that run Microsoft certified training programs and seminars, including intensive system administration training at basic and advanced levels. A beginner needs several weeks of these courses, particularly if programming courses are required. Other alternatives include college courses in programming. (C language is a frequent course offering, even at community colleges.) You'll also find frequent one- and two-day seminars on system administration subjects such as Perl.
The decisions you make on the management of your Intranet, theoretically discussed in Chapter 2, come back into play when you consider the skill sets your people need. (Of course, this statement is easily stood on its head: The skills your people have can help you choose the administrative model and might lead you to reconsider earlier decisions.)
If you choose the decentralized model, you're deciding to leave most, if not all, of the management and development of your Web to its users, or at least to those interested enough to be setting up individual Web servers for their own data. This model also assumes the skills needed to do Web server setup, creation of HTML files, and so forth, best reside at the user level. Similarly, the need for training will be at the same level, with your customers themselves deciding who needs what in the way of training.
In the centralized model these decisions are reversed, with the delegation of responsibilities and the necessary skills focused on your Webmaster(s). Here, you and your Webmaster(s) can determine where training is required and, as noted previously, what training you can provide to your customers, to develop and manage the training process. In the more realistic mixed model, you delegate responsibilities in a more flexible fashion, based on the needs of the components of your organization.
It's also important for you to develop policies about customer contributions to your Web. Besides regular customer feedback (see the following), you should anticipate, if not solicit and welcome, resources for your Intranet that are contributed by your customers. Even if your Intranet follows the centralized model of administration, it's important you recognize that customers often have the best idea of what they want to see on it-especially if it's in their area of expertise. Empowering customer input by providing a way for them to contribute resources directly to your Intranet is a fine way of developing both customers and your Intranet and is sure to lead to further contributions.
We've already mentioned general System Administration training opportunities. You'll also find a wide variety of Web-specific training offerings from commercial vendors as well as short seminars associated with major expositions and conferences. In fact, several Web-specific conferences are already occurring on a regular basis; you'll find advertisements for them in publications devoted to Web subjects and networking. Here are a few:
| Tip |
The first and foremost technical reference that every Windows NT System Administrator should have is the Windows NT Resource Kit published by Microsoft Press. The Resource Kit for NT 3.51 totaled five volumes. If you haven't already purchased the Resource Kit, be sure you wait until the Resource Kit for NT 4 comes out, because so much of the operating system has been enhanced. |
You'll find courses in Web server administration, HTML markup, CGI scripting, Perl, Java programming, VRML, network security, and so on. In these publications, you'll also, find useful articles on Web-related subjects, including technical features. Figure 4.3 shows the Web Developer magazine home page. If you want to stay up on the hottest Web technology, it is a useful place to drop by.
Figure 4.3: The Web Developer magazine home page includes current news about the Web.
If you have a competent Webmaster, there is no reason not to tap her knowledge in running your own training courses on these same subjects. She'll undoubtedly be answering questions from customers on a regular basis, so you might as well formalize this relationship with training courses. Of course, Webmasters cannot only train the people who will use your Intranet, but other Webmasters as well. Don't neglect the value of the wide variety of Web-related books as training tools for users.
In Chapter 2, I recommended use of customer focus groups to help define the purpose and content of your Intranet. You should continue meeting with your focus groups even after your Intranet is up and running; you might find even more valuable feedback from your customers. Also expect customer feedback outside your formal focus group arrangements.
Once your customers get the idea of using Web technology in their everyday work, as opposed to recreational Web surfing, they'll begin bombarding you with suggestions for changes and requests for new information. Listen to these suggestions and requests. As Chapter 2 suggested, your customers know best the kinds of information they want to see and how well your Web presents it. Employees often have useful ideas on how to go about doing their jobs because they are the people most intimately familiar with the jobs. Expect them to have ideas for your Intranet as well for exactly the same reason.
If you've ever designed a database application, you know the iterative design process. Even having gone through a formal process of soliciting user input on your application before you ever started its design, within minutes of the time you sit a user down in front of your prototype, he's asking questions. For example:
In other words, real users using your application-whether it's a corporate database or your Intranet- will quickly have ideas on how it can be made better. Most of their ideas will be good ones, too.
In your Intranet, customer ideas won't be limited to requests for new information or changes in presentation. Users will quickly recognize the collaborative aspects of Web technology. Chapter 27, "Collaboration on Your Intranet," discusses more about this aspect, but I should touch on it here. Chapter 2, for instance, suggested the idea of engineers and scientists sharing engineering drawings, application datafiles, and/or technical reports with colleagues by placing them on your Web. As a Web designer, you can't possibly identify this sort of specific information, but your engineer and scientist customers surely can and will.
Regardless of the administrative model you've selected for your Web, it's important you make it easy for customers to contribute resources for it. This is where the decentralized and mixed models shine: Customers using your Web can create and make their own resources available on your Web for sharing with other customers.
Simple HTML markup is easily within the grasp of just about anyone who uses a computer, as are most of the legacy data conversion tools described in Chapter 3. Point-and-click setup of a Windows Web server makes it possible for almost anyone to set up a bare-bones Web server on his desktop to share these specific resources. Just as anyone can thumb tack a notice on a cork bulletin board in the office, on your Intranet he can tack up CAD drawings of circuit boards, building blueprints, or directions to the office holiday party. You might also want to set up a free-for-all, fill-in form on your Web that allows customers to add links to their resources.
Customer contributions might turn out to be the most important aspect of your Intranet. To this end, make sure your customer training and Web-related communications emphasizes the value and continuing need for their input. It's vitally important that you create a welcoming, inclusive atmosphere. Your Intranet is, after all, for your customers. Involving them in the Intranet design process and then keeping them involved by welcoming their contributions, ensures its value, to them and to your organization. Losing this customer focus, on the other hand, will lead to your Intranet becoming stale and unused; if customers find no value, they'll go elsewhere.
This chapter has focused on the people skills you'll need in setting up, running, and using your Intranet. You've learned about
Chapter 5 furthers the discussion of Intranet fundamentals by diving into HTML. You will find that HTML is really pretty easy to learn, and you will see that these skills are essential to understanding the Web.