(For more resources related to this topic, see here.)
The design documentation provides written documentation of the design factors and the choices the architect has made in the design to satisfy the business and technical requirements.
The design documentation also aids in the implementation of the design. In many cases where the design architect is not responsible for the implementation, the design documents ensure the successful implementation of the design by the implementation engineer.
Once you have created the documentation for a few designs, you will be able to develop standard processes and templates to aid in the creation of design documentation.
Documentation can vary from project to project. Many consulting companies and resellers have standard documentation templates that they use when designing solutions. A properly documented design should include the following information:
This information can be included in a single document or separated into different documents.
VMware provides Service Delivery Kits to VMware partners. These kits can be found on the VMware Partner University portal at http://www.vmware.com/go/partneruniversity, which provides documentation templates that can be used as a foundation for creating design documents. If you do not have access to these templates, example outlines are provided in this article to assist you in developing your own design documentation templates.
The final steps of the design process include gaining customer approval to begin implementation of the design and the implementation of the design.
The architecture design document is a technical document describing the components and specifications required to support the solution and ensure that the specific business and technical requirements of the design are satisfied.
An excellent example of an architecture design document is the Cloud Infrastructure Architecture Case Study White Paper article that can be found at http://www.vmware.com/files/pdf/techpaper/cloud-infrastructure-achitecture-case-study.pdf.
The architect creates the architecture design document to document the design factors and the specific choices that have been made to satisfy those factors. The document serves as a way for the architect to show his work when making design decisions. The architecture design document includes the conceptual, logical, and physical designs.
The architecture design document should include the following information:
The Purpose and Overview section of the architecture design includes the Executive Summary section. The Executive Summary section provides a high-level overview of the design and the goals the design will accomplish, and defines the purpose and scope of the architecture design document.
The following is an example executive summary in the Cloud Infrastructure Architecture Case Study White Paper :
Executive Summary: This architecture design was developed to support a virtualization project to consolidate 100 existing physical servers on to a VMware vSphere 5.x virtual infrastructure. The primary goals this design will accomplish are to increase operational efficiency and to provide high availability of customer-facing applications.
This document details the recommended implementation of a VMware virtualization architecture based on specific business requirements and VMware recommended practices. The document provides both logical and physical design considerations for all related infrastructure components including servers, storage, networking, management, and virtual machines.
The scope of this document is specific to the design of the virtual infrastructure and the supporting components.
The purpose and overview section should also include details of the design methodology the architect has used in creating the architecture design. This should include the processes followed to determine the business and technical requirements along with definitions of the infrastructure qualities that influenced the design decisions.
Design factors, requirements, constraints, and assumptions are documented as part of the conceptual design. To document the design factors, use a table to organize them and associate them with an ID that can be easily referenced.
The following table illustrates an example of how to document the design requirements:
ID |
Requirement |
R001 |
Consolidate the existing 100 physical application servers down to five servers |
R002 |
Provide capacity to support growth for 25 additional application servers over the next five years |
R003 |
Server hardware maintenance should not affect application uptime |
R004 |
Provide N+2 redundancy to support a hardware failure during normal and maintenance operations |
The conceptual design should also include tables documenting any constraints and assumptions. A high-level diagram of the conceptual design can also be included.
Details of the logical design are documented in the architecture design document. The logical design of management, storage, network, and compute resources should be included. When documenting the logical design document, any recommended practices that were followed should be included. Also include references to the requirements, constraints, and assumptions that influenced the design decisions.
When documenting the logical design, show your work to support your design decisions. Include any formulas used for resource calculations and provide detailed explanations of why design decisions were made.
An example table outlining the logical design of compute resource requirements is as follows:
Parameter |
Specification |
Current CPU resources required |
100 GHz |
*CPU growth |
25 GHz |
CPU required (75 percent utilization) |
157 GHz |
Current memory resources required |
525 GB |
*Memory growth |
131 GB |
Memory required (75 percent utilization) |
821 GB |
Memory required (25 percent TPS savings) |
616 GB |
*CPU and memory growth of 25 additional application servers (R002) |
Similar tables will be created to document the logical design for storage, network, and management resources.
The physical design documents have the details of the physical hardware chosen along with the configurations of both the physical and virtual hardware. Details of vendors and hardware models chosen and the reasons for decisions made should be included as part of the physical design. The configuration of the physical hardware is documented along with the details of why specific configuration options were chosen. The physical design should also include diagrams that document the configuration of physical resources, such as physical network connectivity and storage layout.
A sample outline of the architecture design document is as follows:
The implementation plan documents the requirements necessary to complete the implementation of the design.
The implementation plan defines the project roles and defines what is expected of the customer and what they can expect during the implementation of the design.
This document is sometimes referred to as the statement of work. It defines the key points of contact, the requirements that must be satisfied to start the implementation, any project documentation deliverables, and how changes to the design and implementation will be handled.
The implementation plan should include the following information:
The purpose statement defines the purpose and scope of the document. The purpose statement of the implementation plan should define what is included in the document and provide a brief overview of the goals of the project. The purpose statement is simply an introduction so that someone reading the document can gain a quick understanding of what the document contains.
The following is an example purpose statement:
This document serves as the implementation plan and defines the scope of the virtualization project. This document identifies points of contact for the project, lists implementation requirements, provides a brief description of each of the document deliverables, deliverables, and provides an overview of the implementation process for the data-center virtualization project.
The scope of this document is specific to the implementation of the virtual data-center implementation and the supporting components as defined in the Architecture Design.
Key project contacts, their roles, and their contact information should be included as part of the implementation plan document. These contacts include customer stakeholders, project managers, project architects, and implementation engineers.
The following is a sample table that can be used to document project contacts for the implementation plan:
Role |
Name |
Contact information |
Customer project sponsor |
|
|
Customer technical resource |
|
|
Project manager |
|
|
Design architect |
|
|
Implementation engineer |
|
|
QA engineer |
|
|
Support contacts for hardware and software used in the implementation plan may also be included in the table, for example, contact numbers for VMware support or other vendor support.
Implementation requirements contain the implementation dependencies to include the access and facility requirements. Any hardware, software, and licensing that must be available to implement the design is also documented here.
Access requirements include the following:
Facility requirements include the following:
Hardware, software, and licensing requirements include the following:
A high-level overview of the steps required to complete the implementation is also documented. The details of each step are not a part of this document; only the steps that need to be performed will be included. For example:
The implementation overview may also include an implementation timeline documenting the time required to complete each of the steps.
Project documentation deliverables are defined as part of the implementation plan. Any documentation that will be delivered to the customer once the implementation has been completed should be detailed here. Details include the name of the document and a brief description of the purpose of the document.
The following table provides example descriptions of the project documentation deliverables:
Document |
Description |
Architecture design |
This is a technical document describing the vSphere components and specifications required to achieve a solution that addresses the specific business and technical requirements of the design. |
Implementation plan |
This identifies implementation roles and requirements. It provides a high-level map of the implementation and deliverables detailed in the design. It documents change management procedures. |
Installation guide |
This document provides detailed, step-by-step instructions on how to install and configure the products specified in the architecture design document. |
Validation test plan |
This document provides an overview of the procedures to be executed post installation to verify whether or not the infrastructure is installed correctly. It can also be used at any point subsequent to the installation to verify whether or not the infrastructure continues to function correctly. |
Operational procedures |
This document provides detailed, step-by-step instructions on how to perform common operational tasks after the design is implemented. |
How changes are made to the design, specifically changes made to the design factors, must be well documented. Even a simple change to a requirement or an assumption that cannot be verified can have a tremendous effect on the design and implementation. The process for submitting a change, researching the impact of the change, and approving the change should be documented in detail.
The following is an example outline for an implementation plan:
The installation guide provides step-by-step instructions for the implementation of the architecture design. This guide should include detailed information about how to implement and configure all the resources associated with the virtual datacenter project.
In many projects, the person creating the design is not the person responsible for implementing the design. The installation guide outlines the steps necessary to implement the physical design outlined in the architecture design document.
The installation guide should provide details about the installation of all components, including the storage and network configurations required to support the design. In a complex design, multiple installation guides may be created to document the installation of the various components required to support the design. For example, separate installation guides may be created for the storage, network, and vSphere installation and configuration.
The installation guide should include the following information:
The purpose statement simply states the purpose of the document. The assumption statement describes any assumptions the document's author has made. Commonly, an assumption statement simply states that the document has been written, assuming that the reader is familiar with virtualization concepts and the architecture design.
The following is an example of a basic purpose and assumption statement that can be used for an installation guide:
Purpose: This document provides a guide for installing and configuring the virtual infrastructure design defined in the Architecture Design.
Assumptions: This guide is written for an implementation engineer or administrator who is familiar with vSphere concepts and terminologies. The guide is not intended for administrators who have no prior knowledge of vSphere concepts and terminology.
The installation guide should include details on implementing all areas of the design. It should include configuration of the storage array, physical servers, physical network components, and vSphere components. The following are just a few examples of installation tasks to include instructions for:
The installation guide should provide as much detail as possible. Along with the step-by-step procedures, screenshots can be used to provide installation guidance.
The following screenshot is an example taken from an installation guide that details enabling and configuring the Software iSCSI adapter:
The following is an example outline for an installation guide:
The validation test plan documents how the implementation will be verified. It documents the criteria that must be met to determine the success of the implementation and the test procedures that should be followed when validating the environment. The criteria and procedures defined in the validation test plan determine whether or not the design requirements have been successfully met.
The validation test plan should include the following information:
The purpose statement defines the purpose of the validation test plan and the assumption statement documents any assumptions the author of the plan has made in developing the test plan. Typically, the assumptions are that the testing and validation will be performed by someone who is familiar with the concepts and the design.
The following is an example of a purpose and assumption statement for a validation test plan:
Purpose: This document contains testing procedures to verify that the implemented configurations specified in the Architecture Design document successfully addresses the customer requirements.
Assumptions: This document assumes that the person performing these tests has a basic understanding of VMware vSphere and is familiar with the accompanying design documentation. This document is not intended for administrators or testers who have no prior knowledge of vSphere concepts and terminology.
The success criteria determines whether or not the implemented design is operating as expected. More importantly, these criteria determine whether or not the design requirements have been met. Success is measured based on whether or not the criteria satisfies the design requirements.
The following table shows some examples of success criteria defined in the validation test plan:
Description |
Measurement |
Members of the active directory group vSphere administrators are able to access vCenter as administrators |
Yes/No |
Access is denied to users outside the vSphere administrators active directory group |
Yes/No |
Access to a host using the vSphere Client is permitted when lockdown mode is disabled |
Yes/No |
Access to a host using the vSphere Client is denied when lockdown mode is enabled |
Yes/No |
Cluster resource utilization is less than 75 percent. |
Yes/No |
If the success criteria are not met, the design does not satisfy the design factors. This can be due to a misconfiguration or error in the design. Troubleshooting will need to be done to identify the issue or modifications to the design may need to be made.
Test procedures are performed to determine whether or not the success criteria have been met. Test procedures should include testing of usability, performance, and recoverability. Test procedures should include the test description, the tasks to perform the test, and the expected results of the test.
The following table provides some examples of usability testing procedures:
Test description |
Tasks to perform test |
Expected result |
vCenter administrator access |
Use the vSphere Web Client to access the vCenter Server. Log in as a user who is a member of the vSphere administrators AD group. |
Administrator access to the inventory of the vCenter Server |
vCenter access: No permissions |
Use the vSphere Web Client to access the vCenter Server. Log in as a user who is not a member of the vSphere administrators AD group. |
Access is denied |
Host access: lockdown mode disabled |
Disable lockdown mode through the DCUI. Use the vSphere Client to access the host and log in as root. |
Direct access to the host using the vSphere Client is successful |
Host access: lockdown mode enabled |
Re-enable lockdown mode through the DCUI. Use the vSphere Client to access the host and log in as root. |
Direct access to the host using the vSphere Client is denied |
The following table provides some examples of reliability testing procedures:
Test description |
Tasks to perform test |
Expected result |
Host storage path failure |
Disconnect a vmnic providing IP storage connectivity from the host |
The disconnected path fails, but I/O continues to be processed on the surviving paths. A network connectivity alarm should be triggered and an e-mail should be sent to the configured e-mail address. |
Host storage path restore |
Reconnect the vmnic providing IP storage connectivity |
The failed path should become active and begin processing the I/O. Network connectivity alarms should clear. |
Array storage path failure |
Disconnect one network connection from the active SP |
The disconnected paths fail on all hosts, but I/O continues to be processed on the surviving paths. |
Management network redundancy |
Disconnect the active management network vmnic |
The stand-by adapter becomes active. Management access to the host is not interrupted. A loss-of-network redundancy alarm should be triggered and an e-mail should be sent to the configured e-mail address. |
These are just a few examples of test procedures. The actual test procedures will depend on the requirements defined in the conceptual design.
The following is an example outline of a validation test plan: