Configuration Management Body of Knowledge

Chapter 5: Tool Management

Overview

The management of CM Tools varies considerably and the tools themselves are very diverse. Today's CM environments contain a vast array of tools and methods by which the day-to-day jobs are performed. There are dozens of vendors, offering a variety of tools and functional support. Many CM environments, working on limited budgets, are forced to create their own tools out of things like Microsoft Access or other programming tools they might have at hand. Still other CM environments are so strapped for funding, that they are forced to do everything by hand, using spreadsheets and email.

It is not our intent to describe specific vendor tools. This section will describe the nature of the CM activities and the kinds of tools that can be used to automate them. We will describe the capability needed, and the tool resources required to manage the tools once selected.

5.1 TOOL KIT

Beyond the project management tools that could be implemented, Configuration Management has needs for tools to support the plan's requirements. These tools often fail to integrate with project management tools, and as such are seen as additional expenditures which must be justified to the project/organization.

Probably the first tool incorporated into the CM Tool Mix is a tool which automates Version Control for the product at hand. Usually, these are related to Software efforts, but hardware CM benefits from similar tools. Version Control Automation Tools (VCATs) have a wide range of pricing from free to over $600 per seat. Some of the VCATs interface with other tools. Some are home grown. Most every VCAT does the basic check-out/check-in function in a reliable fashion. VCATs can benefit most any size of project, and reduce risk by controlling versioning of items recorded in the VCAT. VCATs also enhance CM's ability to provide accurate reports on change activity.

Another tool incorporated into the CM Tool Mix is a tool which automates problem report tracking. Automated Problem Report Tracking Tools (APRTT) have a wide range of pricing from free to over $600 per seat. There are vendors which sell APRTTs which interface with other tools. Some are home grown by specific projects. Most every APRTTs does the basic problem report data entry and tracking reliably, but the functionality can vary dramatically. Serious evaluation of the candidates for acquisition is encouraged. For large projects, APRTTs eliminate, or greatly reduce the nightmare and flood of huge quantities of problem reports. Such systems also streamline reporting and enhance CM's ability to provide accurate status accounting.

Library Automation Tools

(LATs) don't seem to be as common as the aforementioned tools. These tools automate the tracking systems for physical libraries or storage areas. Normally these are home-grown tools using what ever database or software is available to the configuration team. LATs benefit CM efforts by allowing users of a library or storage area to quickly identify the location of a stored item and retrieving it.

Work Flow Management Tools

(WFMTs) are tools which automate and streamline the process for the entire project. There are some Vendored tools which incorporate this feature into existing tools, while other CM projects work to develop their own. WFMTs can have had dramatic savings in processing of problem reports, by reducing the 'wait' time for the next step in the process to be initiated.

Requirements Management Tool

(RMT) is a tool that can be developed locally or purchased. It can be as simple as a spreadsheet or as complicated as cross-linked requirements management tools generating Requirement documents. It is very useful to make sure that all CM requirements are fulfilled.

The key to tool selection is to a) understand your environment, b) find what would benefit from automation, c) specify needs and requirements, d) test drive the tool and evaluate, e) make a decision.

5.2 REQUIRED RESOURCES

The kinds of resources required to support these tools go beyond simple funding issues for the tools themselves. Whether the tools are developed in-house or vended, there will need to be resources (time and energy) dedicated to training of project team members or CM team members or both in the use of these tools.

Many of the vended tools do not strictly follow the standards out-of-the-box. This is due to a particular school of thought which says that vended tools should be flexible enough to allow modification to the tools so they can be made to fit any business structure or process. Modification will be required in what is known as trigger development and manipulation. Sometimes Application Program Interfaces (APIs) are made available. There are many Configuration Managers who are not inclined or proficient at coding at this level and therefore may find the tools difficult to control. They may even find themselves unhappy with the results. If a Tools DBA is available on the teams operated by those Configuration Managers, then there will be success. Many have found that businesses frequently alter how they do business with CM Teams, and therefore trigger manipulation can be frequent. Those Configuration Managers fortunate enough to understand triggers and what has to be performed, may not feel the need for a Tools DBA, because they take on the role. The more trigger manipulation is required, the more resource time will be required, potentially taking too much of the Configuration Manager’s attention.

Tools developed in-house will definitely benefit from a dedicated resource working closely with the Configuration Manager to hone the functionality of those tools.

Another school of thought is that vended software should have an ‘out-of-box’ option that upon installation is ready to behave in accordance with a set of standards or life cycle methodology. Most vended tools these days do not have this feature.

Previous: CM Tool Management

Next: CM Activities and Schedules