DBMS - December 1996 - Mothballing a Database Project

DBMS

Mothballing a Database Project

By Michael R. Ault
DBMS, December 1996

A Few Simple Steps can Drastically Increase the Shelf Life of Canceled Projects.

No one likes to admit it, but 31 percent of all new computer projects fail (according to a study conducted by the Standish Group International Inc., a technology consulting firm in Dennis, Mass.). In fact, this 31 percent figure is probably a low estimate. An Information Week readers poll documented in the article "Corporate Migration -- Harder Than It Looks" by Barbara DePompa (December 4, 1995) states that 80 percent of the respondents had to reevaluate, pull back from, or cancel a client/server development project. These failures may result from inexperienced management, scope creep, invalid specifications, or insufficient funding. Whatever the cause, if there is a chance that the project will be reactivated, it must be shut down and mothballed properly. Mothballing a project is not a simple matter of pulling the plug, deleting the code, and walking away -- it requires just as careful planning as a project startup.

Methods of Mothballing

The method used to mothball a project depends on the operating system, hardware, and database development tools used. Each case will be unique and must be planned for in advance. As I noted previously, no one likes to think about failure, but it happens with disturbing frequency and must be dealt with. If you have the level of documentation required for a successful mothball and restart, you can also apply this data to disaster recovery. A properly mothballed project consists of both documentation and media backups of programs and source code and even some data, including lookup tables.

Operating System Backup

Depending on the database system in use, you must employ different methods to ensure that the project can be restarted. The simplest method is the system backup, which will copy database system executables and the files that are used to store the database data, journals, and control files. However, database systems are not static entities; most database systems will undergo at least two major upgrades in a year. If a project is mothballed for a year or longer, it may be woefully out of date and virtually unrecoverable if this is the only method used for backup of the system files.

On an Oracle system, for example, you may have to recover the old database, export it or generate DDL (Data Definition Language), remove the old database (or upgrade on the spot), and then import or re-create the database under the new version if a system backup is all that is done to allow for project recovery. In some cases, operating system changes may prevent the backups from being reapplied.

Exports or Logical Copies

Many DBMSs such as Oracle support export of a logical copy of the database that will include the data definitions as well as the data stored in the database. One of the major benefits of the export process is that upward mobility is usually assured for several releases; that is, an export taken on version 7.1 can probably be imported into version 7.3 or even 8.0 and later. However, most exports will not be readable by other database systems, so if you aren't sure that you will be rebuilding the application on the DBMS for which it was initially conceived, an export will probably not allow a rebuild of the application without completely reinstalling the old database system first.

Exports will allow a much smaller recovery footprint than an operating system backup. Because an export is a logical copy, the only items that get backed up are those that are required for rebuilding the database or even a section of the database (Oracle allows database-, schema-, and table-level exports).

Data Definition Language Scripts

The most atomic-level backup of a database system is the actual DDL code, usually SQL or a SQL derivative. With minor modifications, the DDL from one database system that conforms to SQL standards can be applied to any other that also complies with the standards.

Tables, indexes, constraints, views, packages, procedures, triggers, and other structures may be a part of the DDL for a specific application. Each of these types of database objects should be built using separate scripts. Separately built scripts for sets of like database objects make it easier to make modifications later, should the structure of the command to build these objects differ in the target database system. Unfortunately, most database systems do not provide DDL generators to create these atomic-level scripts. If you use a CASE system to build your system, many CASE systems let you generate a specific type of object DDL, and many support multiple database system syntax. However, if a CASE tool was not used and a third-party DBA tool that has a DDL generation utility is not available, your only recourse is to generate the DDL scripts manually. Most systems will have data dictionary tables that can be queried like any other database tables, allowing the DDL to be dynamically generated for each type of database object. When documenting the application, do not forget to document all initialization parameters and physical database structures as well. In Oracle, the initialization parameters will be documented in the init_<SID>.ora file, where the SID is the database identifier. The physical structures in Oracle are documented in the data dictionary tables or can be documented using simple Oracle system commands. Other databases have similar features.

Documentation

Documentation is the last factor involved in mothballing a project. You must capture as much as possible of the thought and creative impulses that put the project together. If a CASE tool was used, much of this information will already be present in the CASE tool's files. If a CASE tool isn't used, this information must be extracted from the developers and designers. Unfortunately, the first thing usually done in a project shutdown is the release of any and all contract personnel: In most cases, these employees will be your experts brought in for the project. Do not let people go until they have fully documented their sections of code. In addition, you should capture their thoughts on additions, changes, and improvements that can be made with the application modules for which they are responsible.

An example documentation set would consist of:

Executive overview. This document explains the project and the project components, and it gives a brief explanation of the rest of the documentation set. It should contain the locations for all pertinent documents and archives.
Hardware overview. This document contains all of the specifications for the system hardware. The document should contain required CPU, IO, and disk requirements as well as networking needs. Remember to document server and client requirements separately, because they are almost always different.
Code listings of all applications generated in-house. These code listings can be either hardcopy printouts (not the most efficient form) or archived text files on removable media such as tape. Code listings should contain a header that describes each module, lists the author, and lists inputs and outputs. Code listings should also contain comments that explain each section of the code and describe any "special" code sections that are not obvious in function or content. Documenting the code in an object-based application is far more complicated, because various event handlers contain buried code. You should also document any properties set using property sheets.
Runbooks that document each executable generated for the application. Runbooks contain installation instructions, operational instructions, and troubleshooting guides.
Important project documents. Important documents consist of -- but are not limited to -- design documents, change logs, system integration test results, user- acceptance test plans and results, and correspondence logs. If you use an automated testing application, test plans should also be documented, possibly by creating reports from the testing software package used.
Skill sets. Documentation does not end with pages of text describing application modules. Skill sets must also be documented -- the management of the entire project will likely change by the time it is reactivated, and documentation of the required skill sets will ensure that the proper re-staffing occurs.
Tools. All tools used on the project should be documented just as the application modules are documented. These tools become a part of the required expertise for the project if it is reactivated --for example, the CASE tools used to design and implement the DDL for the application. If the knowledge requirements for the tools aren't captured when the project is reactivated, you may lose vital time searching for the right person with the proper tool knowledge. This section should include a list of vendors and how to contact them, especially technical support personnel. Also, agreement numbers for tech support contracts should be documented in case the contracts do not expire or are based on usage events and not time periods.
Reasons for project mothballing. Perhaps the most difficult documentation to produce, this is not a face-saving document -- it should be as accurate and complete as is possible. Try to stick to the facts and exclude opinions. Of all the documents, this may be one of the most important, because it will point out to the new project leaders what went wrong so that they may be able to avoid the pitfalls that shelved the project in this first attempt.
Contact list. Even though it may get out of date rather quickly in these transient times, you should include a contact list of all members of the team. The contact list should include phone numbers, addresses, and skill-set matrices for all team members. If the project is reactivated, this list may provide vital contact points to get back the original team or personnel recommended by the original team members.
Setup instructions. Each type of database has different file layouts and disk arrangements. If the application has any special considerations in this area, they must be documented. An example would be Oracle's Optimal Flexible Architecture (OFA) methodology, which delineates the method by which Oracle data files should be set up.
Training materials. If the project was far enough along, training materials will already have been developed. These materials will probably consist of examples, perhaps a written manual, and a participants' guide of some kind. Include this material with your documentation set.
Team members' comments. Capture an honest and detailed report, with suggestions for improvement of the project, from each of the team members. These reports should contain opinions as well as factual data. This process gives the team members a feeling of closure. If they were not able to complete the project, they will at least get the chance to explain in their own words what they feel went wrong and how to avoid it in the future.
Tape or backup media copies. These media copies should include all source code, DDL, export sets, or backup sets that would let the new team rebuild the system as it existed on the day of shutdown. It is also a good idea to include the tape drive software used to make the backups. Believe it or not, future tape drives may not read tapes made with older versions of the software. Any special setup or handling requirements should also be provided. If you used a CASE tool to cut an extract set from the CASE tool's tables for this project, include the extract with this information.

Now What?

The project has been backed up, the documentation has been gathered, and the team's skills and feelings about the project are compiled. What do you do with this data? If you are the prime contractor, be sure to keep a full copy for your records. If you are the company that started the project, be sure you have the documentation, including the tapes or backup media in at least two safe locations that are documented (in the lead engineer's desk drawer under his or her lunch isn't a good location). If you are using a software management system, most of the data will be captured there, but a hard set of documentation is always a good idea.

To Fail is Human

The high failure rate of major projects is an unfortunate fact of modern application development. As software and application development professionals, it is our duty to ensure that a canceled project can be reactivated if the need arises. In light of this duty, we need to understand what constitutes a properly mothballed project. To summarize, if you do not feel certain that the project could be restarted with new management and team members from the documentation and backups you have, then the project is not mothballed properly. Put yourself in the shoes of the next team to have this project thrust upon them: Would you want to restart the project with the quality of documentation that currently exists? If your answer is "No," you should immediately begin corrective action to make it so. It is much easier to carry proper documentation throughout a project life cycle than to play catch-up after the project has been mothballed.

Michael R. Ault is a senior consultant for TreCom Business Systems, a consulting and professional service of Amdahl Corp. He is also the author of Oracle7.0 Administration and Management and Unix System Administrator's Companion (John Wiley & Sons, 1994 and 1995 respectively), and is a senior technology officer for RevealNet Inc. You can email Michael at 73564.544@compuserve.com.

Please send questions or comments to dbms@mfi.com
Updated Monday, November 18, 1996