| The physical design can be documented in a number of different ways. Large environments, such as HP and Reed Elsevier, created separate documents on virtually every major section of this chapter. Smaller enterprises , such as GDOT, created a single document that comprised the logical and physical design as well as the pilot. The section headings in this chapter can be used as a guide in creating the design documents, just as the table of contents of Chapters 4 and 5 can be used to create the assessment and logical design documents, respectively. Some ideas for creating the documents include -
Consider taking the table of contents listing ”to about the third heading level ”and assign various topics to your design team. Determine at what level the documents should be created. For instance, you might have a single document titled Physical Design, which contains all the technologies described in this chapter, or you might want to break it down so that there is one document on Server Placement, one on DNS Design, and so on. This will depend on the amount of data that will be contained in each section, what level of detail you want to document, and the number of staff members available. -
Assign a member of each team to be responsible for the documentation. -
Create templates for the documents that define styles for headers, captions, figures, tables, and so on, as well as title information; and change control tables that track document revisions. -
The project manager should periodically review the documents for completeness and accuracy. Documentation seems to be a task that is put off until the end, and then you can't remember the details. Keep the docs up-to-date as the migration progresses. -
Consider creating the Build Guides, step-by-step descriptions of various installation and configuration processes as described in the "Build Guides" section of this chapter. Accurate documentation will provide a number of benefits to the project manager, the design team, and the Administrators. These benefits include -
Design review : Having the design well documented allows for a critical design review. Consider having a qualified third party that has not had a hand in the design review the design docs. I have done this for a number of HP customers and invariably turn up something they missed. Of course, with no design doc, this can't take place. -
Implementation : A well-documented design will have a high degree of success at implementation because the intentions of the design will be of sufficient detail that implementation will be well defined. Again, consider using the Build Guides described in this chapter to further define the implementation. -
Management and troubleshooting : In the production environment, the design documentation can be helpful in finding the root cause of problems by seeing how it was designed, how it changed, and if the design was flawed. If a consultant was used to create the design or part of the design, good documentation will help the IT staff determine what the consultant did. Producing accurate documentation is important to the overall success of the migration. |