In most instances, a single individual should be selected to own the configuration process. The desired characteristics of this process owner are listed and prioritized in Table 14-1. The process owner should have strong working knowledge of system and network software and their components as well as strong knowledge of software and hardware components. Other preferred attributes include knowledge of applications and desktop systems and the ability to think and act tactically. In some extremely large infrastructure organizations, there may be subprocess owners each for networks, systems, and databases. Even in this case there should be a higher-level manager, such as the technical services manager or even the manager of the infrastructure, to whom each subprocess owner reports.

Most shops have access to a technical writer who can generate narratives, verbiage, or procedures; or they have access to a documentation analyst who can produce diagrams, flowcharts, or schematics. Offering the services of one of these individuals, even if only for short periods of time, can reap major benefits in terms of technicians producing clear, accurate documentation in a fairly quick manner.

Another benefit of this approach is that it removes some of the stigma that many technical specialists have about documentation. Most technicians derive their satisfaction from designing, implementing, or repairing sophisticated systems and networks, not from writing about them. Having an assistant to do much of the nuts-and-bolts writing can ease both the strain and the effort technicians feel when required to do documentation.

One of the concerns raised about the use of technical writers or documentation analysts is their expense. In reality, the cost of extended recovery times that are the result of outdated documentation on critical systems and networks—particularly when localized disasters are looming—far exceeds the salary of one full-time-equivalent scribe. Documentation costs can further be reduced by contracting out for these services on a part-time basis, by sharing the resource with other divisions, and by using documentation tools to limit labor expense. Such tools include online configurators and network diagram generators.

This suggestion builds on the prior improvement recommendation of having a technical writer or documentation analyst work directly with the originator of the system being written about. Infrastructure documentation comes in a variety of flavors but generally falls into five broad configuration categories:

There are obvious subcategories such as networks breaking out into LANs, wide-area networks (WANs), backbones, and voice.

The point here is that the more you can match the background of the technical writer to the specifications of the documentation, the better the finished product. This will also produce a better fit between the technician providing the requirements and the technical writer who is meeting them.

Evaluating existing documentation can reveal a great deal about the quality and value of prior efforts at recording current configurations. Identifying which pieces of documentation are most valuable to an organization, and then rating the relative quality of the content, is an excellent method to quickly determine which areas need improvements the most.

In Chapter 20, “Using Technology to Automate and Evaluate Robust Processes,” we present a straightforward technique to conduct such an evaluation. It has proven to be very helpful at several companies, especially those struggling to assess their current levels of documentation.

Different models of server hardware may support only limited versions of operating system software. Similarly, different sizes of disk arrays will support differing quantities and types of channels, cache, disk volumes, and densities. The same is true for tape drive equipment. Network components (such as routers and switches) and desktop computers all come with a variety of features, interconnections, and enhancements.

Hardware suppliers, while often the most qualified, are least involved in assisting with a client’s documentation. This is not to say the supplier will generate free detailed diagrams about all aspects of a layout, although I have experienced server and disk suppliers who did just that. But most suppliers will be glad to help keep documentation about their equipment current and understandable. It is very much in their best interest to do so, both from a serviceability standpoint and from a marketing one. Sometimes all it takes is asking.

Similar to their hardware counterparts, infrastructure software suppliers can be an excellent source of assistance in documenting which levels of software are running on which models of hardware. In the case of servers and operating systems, the hardware and software suppliers are almost always the same. This reduces the number of suppliers with whom you may need to work, but not necessarily the complexity of the configurations.

For example, one of my clients had hundreds of servers almost evenly divided among the operating systems HP/UNIX, Sun/Solaris, and Microsoft/NT with three or four variations of versions, releases, and patch levels associated with each supplier. Changes to the software levels were made almost weekly to one or more servers, requiring almost continual updates to the software and hardware configurations. Assistance from the suppliers as to anticipated release levels and the use of an online tool greatly simplified the process.

Software for database management, performance monitoring, and data backups also comes in a variety of levels and for specific platforms. Suppliers can be helpful in setting up initial configurations such for complex disk to tape backup schemes and may also offer online tools to assist in the upkeep of the documentation.

The upgrading of major hardware components such as multiple servers or large disk arrays can render volumes of configuration documentation obsolete. The introduction of a huge corporate database or an enterprise-wide data warehouse could significantly alter documentation about disk configurations, software levels, and backup servers. Coordinating in advance and simultaneously the many different documentation updates with the appropriate individuals can save time, reduce errors, and improve cooperation among disparate groups.

One of the most challenging of configuration management tasks involves the number, types, and features of desktop equipment. As mentioned previously, we do not include asset management in these discussions of infrastructure processes because many shops turn this function over to a procurement or purchasing department.

Regardless of where asset management is located in the reporting hierarchy, it can serve as a tremendous resource for keeping track of the myriad paperwork tasks associated with desktops, including the names, departments, and location of users; desktop features; software licenses and copies; hardware and software maintenance agreements; and network addresses. Providing asset managers with an online asset management system can make them even more productive both to themselves and to the infrastructure. The configuration management process owner still needs to coordinate all these activities and updates, but he or she can utilize asset management to simplify an otherwise enormously tedious task.