<<Project Name>>

Physical Design

 

Customer Name

 

 

Directions for using template:

Read the Guidance (Arial blue font in brackets) to understand the information that should be placed in each section of this template. Then delete the Guidance and replace the placeholder within <<Begin text here>> with your response. There may be additional Guidance in the Appendix of some documents, which should also be deleted once it has been used.

 

Some templates have four levels of headings.  They are not indented, but can be differentiated by font type and size:

You may elect to indent sections for readability.

 

 

 

Author

 

Author Position

 

Date

 

 

 

 

 

Version: 1.0

 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2002 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft and Visual Basic are either registered trademarks or trademarks of Microsoft in the United States and/or other countries.

 


 

Revision & Sign-off Sheet

Change Record

Date

Author

Version

Change Reference

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Reviewers

Name

Version Approved

Position

Date

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Distribution

Name

Position

 

 

 

 

 

 

 

 

 

Document Properties

Item

Details

Document Title

Physical Design

Author

 

Creation Date

 

Last Updated

 

 



 

Table of Contents

Physical Design Summary. 4

Environment Constraints, and Assumptions. 4

Dependencies. 4

Project Dependencies. 4

Hardware Environment Dependencies. 4

Software Environment Dependencies. 5

Application Development 5

User Services (UI Ė User Interface) 5

Component <<Component Name>> Design. 5

Business Services (Middle-tier Business Logic) 7

Component <<Component Name>> Design. 7

Data Services Tier 9

Component <<Component Name>> Design. 9

Database Design. 11

Infrastructure Deployment 12

Solution Topologies. 12

Intranet Communication. 12

Services. 12

Protocols. 12

Security. 13

Internet Communication. 13

Services. 13

Protocols. 13

Security. 13

Extranet Communication. 13

Services. 14

Protocols. 14

Security. 14

Network Diagnostics Impact 14

Authentication/Active Directory/NT Domain Strategy. 14

Addressing. 14

Client Tier 15

Server Tier 15

DHCP Configurations. 15

Name Resolution. 15

WINS Configurations. 15

DNS Configurations. 15

Remote Access. 15

Naming Standards. 15

Server Placement 15

Server Sizing. 16

Administrative Model 16

Individual Product/Service Features to be Implemented. 16

Service <<Service Name>> Configuration. 16

Configuration of Environment 16

Security Strategy. 16

Security Design Implications. 17

Security Implementation Issues. 17

Security Operational Support Considerations. 17

Installation and Setup. 17

Hardware Requirements. 17

Software Requirements. 17

Un-Installation. 17

Design for Deployment 18

Design for Migration. 18

Design for Integration. 18

Accessibility Support 18

Multi-language Support 18

Design for Supportability. 18

Logging/Eventing. 19

Error Messages. 19

Diagnostic Tools. 19

Recovery from Corruption/Error Messaging. 19

Issues. 19

Appendix. 20

 


 

[Introduction to the Template

 

Description: The Physical Design is the application of real-world physical design constraints applied to the Logical Design. This is developed by analyzing which pieces of the Logical Design already exist in components, what can be reused or modified, and what new pieces must be created.

 

Justification: The Physical Design is a complete implementation design or blueprint, in the form of a technical specification that the development team will use to build the solution.

 

{Team Role Primary: Program Management is responsible for ensuring that the physical design document is completed. Development will have the primary responsibility for creating the documentís content. Release Management will participate both in content creation and review along with development to ensure that operational, deployment, migration, interoperability, and support needs are addressed within the design.

 

Team Role Secondary: Product Management will review and understand the Physical Design in order to convey it to parties external to the team and to ensure that it aligns with initial project sponsor requirements. User Experience will review the design to ensure user requirements are met. Test will review the Physical Design to ensure test plans are in place to validate it.}]

 

 


 

Physical Design Summary

[Description: Provide an overall summary of the contents of this document. This should include the criteria by which the design was established and how it was validated.

 

Justification: Some project participants may need to know only the documentís highlights, and summarizing creates that user view. It also enables the full reader to know the essence of the document before they examine the details.]

<<Begin text here>>

 

Environment Constraints, and Assumptions

[Description: The Environment Constraints and Assumptions section identifies and defines the conditions that impact the physical design. These may be associated with the current infrastructure into which the solution will be deployed or time and cost constraints that impact the selection of technologies. This section should also identify all assumptions that were made in developing the physical design that need verification.

 

Justification: Documenting these conditions ensures that the development team applied them to the process of creating the design. It also signals to stakeholders external to the team that these conditions were considered.]

<<Begin text here>>

 

Dependencies

[Description: The Dependencies section identifies the project, hardware, and software dependencies and resources required to enable development to begin.]

 

Project Dependencies

[Description:  The Project Dependencies section defines project-related conditions that must be in place for the development team to be successful. This may include having specifically skilled people on the team, depending on an external project, or requiring a deliverable from a related project team.]

<<Begin text here>>

 

Hardware Environment Dependencies

[Description: The Hardware Environment Dependencies section lists and describes the environmental hardware that should be in place for the development teamís work. Itemize all required development workstations and testing environment hardware here.]

<<Begin text here>>

 

Software Environment Dependencies

[Description The Software Environment Dependencies section lists and describes the environmental software that should be in place for the development teamís work. Itemize all required development workstations and testing environment software here.]

<<Begin text here>>

 

Application Development

[Description: The Application Development section describes the design for any applications that exist within the solution. Applications may include custom code and components. The sub-sections provide topic ideas that may help build a cohesive picture of the physical implementation.]

 

User Services (UI Ė User Interface)

[Description:  In n-tier development, the User Services section represents the traditional User Interface (UI). More than just presentation, the solution may have additional client-tier services behind the presentation layer and possibly even a client database implementation. Separate the client database implementation into the data services tier, but do not include it here. This section should focus solely on UI presentation services.

 

Itemize all the components and use the following sub-sections to describe them in detail.]

<<Begin text here>>

 

Component <<Component Name>> Design

[Description: The Component Design section provides details for each component within the architecture. Construct a separate section for each component that includes the applicable sub-sections listed below (Behavioral Summary, Dependencies, etc.).]

 

Behavioral Summary

[Description: The Behavioral Summary section describes the expected component behavior, including a high-level description of services and value.]

<<Begin text here>>

 

Dependencies

[Description: The Dependencies section provides a detailed, unique dependency for each component different from the overall environment dependencies. Detail inter-component dependencies, COM+ role, security context dependencies, memory allocation estimates, and state full dependencies.

 

Justification]

<<Begin text here>>

 

New Application Interfaces

[Description: The New Application Interfaces section describes the interface names, public/private methods, arguments and syntax required of all new interfaces.]

<<Begin text here>>

 

Changed Application Interfaces

[Description: The Changed Application Interfaces section describes the interface names, public/private methods, arguments and syntax required of any existing interfaces that must be changed. This section is optional if this is a revision project or Version 1+ project.]

<<Begin text here>>

 

Removed Application Interfaces

[Description: The Removed Application Interfaces section identifies all application interfaces that are removed for this solution. This section is optional if this is a revision project or Version 1+ project.]

<<Begin text here>>

 

Scripting Interfaces

[Description: The Scripting Interfaces section describes all interface names, public/private methods, arguments, and syntax required.]

<<Begin text here>>

 

Registry Impact Ė Configuration and Settings

[Description: The Registry Impact Ė Configuration and Settings section describes the registry keys created, default configuration, and values.]

<<Begin text here>>

 

Error Messages

[Description:  The Error Messages section identifies all events, exceptions, and errors that may occur within a component. List message descriptions here as well.]

<<Begin text here>>

 

Security Implementation

[Description:  The Security Implementation section describes the security context strategy for the component that will be used in calling context (interactive user) or specific role etc. It should identify additional security beyond COM+ implementation as required. This information should also include dependencies/assumptions made within the context of this componentís execution.]

<<Begin text here>>

 

Component Management Issues

[Description: The Component Management Issues section describes any unique aspects of the component design.]

<<Begin text here>>

 

Business Services (Middle-tier Business Logic)

[Description: The Business Services section defines the application components for the solutionís business services tier. Itemize all the components and use the following sub-sections to describe them in detail.]

<<Begin text here>>

 

Component <<Component Name>> Design

[Description: The Component Design section provides details for each component within the architecture. There should be a separate section for each component that includes the applicable sub-sections listed below (Behavioral Summary, Dependencies, etc.).]

 

Behavioral Summary

[Description: The Behavioral Summary section describes the expected component behavior, including a high-level description of services and value.]

<<Begin text here>>

 

Dependencies

[Description: The dependencies section provides a detailed, unique dependency for each component different from the overall environment dependencies. Detail inter-component dependencies, COM+ role, security context dependencies, memory allocation estimates, and state full dependencies.

Justification]

<<Begin text here>>

 

New Application Interfaces

[Description: The New Application Interfaces section describes the interface names, public/private methods, arguments and syntax required of all new interfaces.]

<<Begin text here>>

 

Changed Application Interfaces

[Description: The Changed Application Interfaces section describes the interface names, public/private methods, arguments and syntax required of any existing interfaces that must be changed. This section is optional if this is a revision project or Version 1+ project.]

<<Begin text here>>

 

Removed Application Interfaces

[Description: The Removed Application Interfaces section identifies all application interfaces that are removed for this solution. This section is optional if this is a revision project or Version 1+ project.]

<<Begin text here>>

 

Scripting Interfaces

[Description: The Scripting Interfaces section describes all interface names, public/private methods, arguments, and syntax required.]

<<Begin text here>>

 

Registry Impact Ė Configuration and Settings

[Description: The Registry Impact Ė Configuration and Settings section describes the registry keys created, default configuration, and values.]

<<Begin text here>>

 

Error Messages

[Description:  The Error Messages section identifies all events, exceptions, and errors that may occur within a component. List message descriptions here as well.]

<<Begin text here>>

 

Security Implementation

[Description:  The Security Implementation section describes the security context strategy for the component that will be used in calling context (interactive user) or specific role etc. It should identify additional security beyond COM+ implementation as required. This information should also include dependencies/assumptions made within the context of this componentís execution.]

<<Begin text here>>

 

Component Management Issues

[Description: The Component Management Issues section describes any unique aspects of the component design.]

<<Begin text here>>

 

Data Services Tier

[Description: The Data Services Tier section is used if the solution requires implementing separate data tier service components in addition to the physical database implementation. If the solution requires implementing the design through extensive data services within a database engine itself, use the ďDatabase DesignĒ section to describe this.

 

Itemize all the components and use the following sub-sections to describe them in detail.]

<<Begin text here>>

 

Component <<Component Name>> Design

[Description: The Component Design section provides details for each component within the architecture. There should be a separate section for each component that includes the applicable sub-sections listed below (Behavioral Summary, Dependencies, etc.).]

 

Behavioral Summary

[Description: The Behavioral Summary section describes the expected component behavior, including a high-level description of services and value.]

<<Begin text here>>

 

Dependencies

[Description: The Dependencies section provides a detailed, unique dependency for each component different from the overall environment dependencies. Detail inter-component dependencies, COM+ role, security context dependencies, memory allocation estimates, and state full dependencies.

 

Justification]

<<Begin text here>>

 

New Application Interfaces

[Description: The New Application Interfaces section describes the interface names, public/private methods, arguments, and syntax required of all new interfaces.]

<<Begin text here>>

 

Changed Application Interfaces

[Description: The Changed Application Interfaces section describes the interface names, public/private methods, arguments, and syntax required of any existing interfaces that must be changed. This section is optional if this is a revision project or Version 1+ project.]

<<Begin text here>>

 

Removed Application Interfaces

[Description: The Removed Application Interfaces section identifies all application interfaces that are removed for this solution. This section is optional if this is a revision project or Version 1+ project.]

<<Begin text here>>

 

Scripting Interfaces

[Description: The Scripting Interfaces section describes all interface names, public/private methods, arguments, and syntax required.]

<<Begin text here>>

 

Registry Impact Ė Configuration and Settings

[Description: The Registry Impact Ė Configuration and Settings section describes the registry keys created, default configuration, and values.]

<<Begin text here>>

 

Error Messages

[Description:  The Error Messages section identifies all events, exceptions, and errors that may occur within a component. List message descriptions here as well.]

<<Begin text here>>

 

Security Implementation

[Description:  The Security Implementation section describes the security context strategy for the component that will be used in calling context (interactive user) or specific role etc. It should identify additional security beyond COM+ implementation as required. This information should also include dependencies/assumptions made within the context of this componentís execution.]

<<Begin text here>>

 

Component Management Issues

[Description: The Component Management Issues section describes any unique aspects of the component design.]

<<Begin text here>>

 

Database Design

[Description:  The Database Design section defines the complete database strategy.]

<<Begin text here>>

 

Database Schema

[Description: The Database Schema section defines the databases, table structures, and field/record descriptions and their structures. The database schema can be represented using a schema-modeling tool.]

<<Begin text here>>

 

Stored Procedures

[Description: The Stored Procedures section describes each stored procedure name, its functionality, parameters/arguments, and transactional support.]

<<Begin text here>>

 

Data Replication Strategy

[Description:  The Data Replication Strategy section defines the type of strategy selected (multi-tier or multi-platform, selected engine, DTS packages, etc) and identifies and describes all unique replication procedures.]

<<Begin text here>>

 

Security Implementation

[Description: The Security Implementation section describes the data security model. This should include descriptions of group administration and role rights within each database and its associated tables. You may choose to consolidate specific security assignments within the schema section above using a visual format in a graph or schema outlay.]

<<Begin text here>>

 

Data Management Strategy

[Description:  The Data Management Strategy section describes the post installation strategy for un-interrupted performance. This should include the technical specifications for implementing that data-management strategy. This section may overlap with the Operations Plan and Support Plan, which can be referenced here.]

<<Begin text here>>

 

Infrastructure Deployment

[Description: The Infrastructure Deployment section is applicable if the solution includes implementing, deploying, and migrating a packaged infrastructure product or service. The sub-sections provide topic ideas that may help build a cohesive picture of the physical implementation.]

 

Solution Topologies

[Description: The Solution Topologies section provides a general explanation of the solutionís topology architecture. This should include physical machine locations, network design topologies, and site topologies. Include both central and remote site topologies if applicable. A visual or graphic depiction of this topology may provide clarity.]

<<Begin text here>>

 

Intranet Communication

[Description: The Intranet Communication section describes the server and services communication strategy within the firewall boundaries for the solution.]

<<Begin text here>>

 

Services

[Description: The Services section itemizes all intranet communication product services to be implemented within the solution.]

<<Begin text here>>

 

Service <<Service Name>> Configuration

[Description: The Service Configuration section describes the installation options, configuration issues, and options for the above-named service. Repeat this section for each service to be implemented.]

<<Begin text here>>

 

Protocols

[Description: The Protocols section itemizes the network protocols supported. This should include a list of configuration options/issues required within all tiers of solution.]

<<Begin text here>>

 

Security

[Description: The Security section lists the security configuration options/requirements specific to intranet communication.]

<<Begin text here>>

 

Internet Communication

[Description: The Internet Communication section describes how the solution will provide for or be dependent upon Internet connectivity. It also defines the perceived impact of the solution upon the existing Internet services, and lists any additional services required (firewall support, encryption/secure communication strategy, etc.).]

<<Begin text here>>

 

Services

[Description: The Services section itemizes all Internet communication product services to be implemented within the solution.]

<<Begin text here>>

 

Service <<Service Name>> Configuration

[Description: The Service Configuration section describes the installation options, configuration issues, and options for the above-named service. Repeat this section for each service to be implemented.]

<<Begin text here>>

 

Protocols

[Description: The Protocols section itemizes the network protocols supported. This should include a list of configuration options/issues required within all tiers of solution.]

<<Begin text here>>

 

Security

[Description: The Security section lists the security configuration options/requirements specific to Internet communication.]

<<Begin text here>>

 

Extranet Communication

[Description: The Extranet Communication section describes how the solution will provide for or be dependent upon Extranet connectivity. It also defines the perceived impact of the solution upon the existing Extranet services, and lists any additional services required (VPN, private network, B2B or partner relationship, trust environments established between partners, etc.).]

<<Begin text here>>

 

Services

[Description: The Services section itemizes all extranet communication product services to be implemented within the solution.]

<<Begin text here>>

 

Service <<Service Name>> Configuration

[Description: The Service Configuration section describes the installation options, configuration issues, and options for the above-named service. Repeat this section for each service to be implemented.]

<<Begin text here>>

 

Protocols

[Description: The Protocols section itemizes the network protocols supported. This should include a list of configuration options/issues required within all tiers of solution.]

<<Begin text here>>

 

Security

[Description: The Security section lists the security configuration options/requirements specific to extranet communication.]

<<Begin text here>>

 

Network Diagnostics Impact

[Description: The Network Diagnostics Impact section describes the changes needed in the physical network, such as any needed new subnets, segments, line speeds, hubs, routers or switching equipment.]

<<Begin text here>>

 

Authentication/Active Directory/NT Domain Strategy

[Description: The Authentication/Active Directory/NT Domain Strategy sectionís title should be modified for the specific solution. It describes the detailed model of the Active Directory implementation, NT Server account domains, resource domains, and trust relationships, LDAP or other authentication strategies. If your solution supports more than one, provide details on each authentication strategy.]

<<Begin text here>>

 

Addressing

[Description: The Addressing section describes the method for network address assignment and management (DHCP/Static IP, etc.). This entire section may not apply to the solution or be greatly reduced in scope if the deployment is exclusive to an isolated environment (i.e., a single instance on a single machine.). However, if planning a large-scale, multi-tier deployment, this section is probably more relevant when each tier is defined independently.]

 

Client Tier

<<Begin text here>>

 

Server Tier

<<Begin text here>>

 

DHCP Configurations

<<Begin text here>>

 

Name Resolution

[Description: The Name Resolution section describes the method for resolving host (server) and client names on the networks (DNS/WINS, etc.).]

 

WINS Configurations

<<Begin text here>>

 

DNS Configurations

<<Begin text here>>

 

Remote Access

[Description: The Remote Access section describes how the feature(s) work when connected via remote access or slow links.]

<<Begin text here>>

 

Naming Standards

[Description: The Naming Standards section defines all naming standards required by the new application or infrastructure environment. This should include naming conventions for components, including server, sites, organization units, workstations, etc.]

<<Begin text here>>

 

Server Placement

[Description: The Server Placement section describes the guidelines for placing servers, both centrally or remote.]

<<Begin text here>>

 

Server Sizing

[Description: The Server Sizing section describes the guidelines for configuring servers.]

<<Begin text here>>

 

Administrative Model

[Description: The Administrative Model section describes how the servers and clients will be administrated.]

<<Begin text here>>

 

Individual Product/Service Features to be Implemented

[Description:  The Individual Product/Service Features to be Implemented section itemizes all products that will be deployed on behalf of the solution and the features of each product/service to be implemented. List the products and use the sub-sections below to describe them in detail.]

<<Begin text here>>

 

Service <<Service Name>> Configuration

[Description: The Service Configuration section describes for each product its installation options, configuration settings at default, any options available, and all issues associated with its deployment.

 

Repeat this section for each service to be implemented.]

<<Begin text here>>

 

Configuration of Environment

[Description:  The Configuration of Environment section defines the overall environment configuration that addresses the solutionís performance, scalability, reliability, and security. In an implementation/deployment/migration project, this section is likely to be extensive.]

<<Begin text here>>

 

Security Strategy

[Description: The Security Strategy section describes the solution-wide strategy to ensure security of all components. This section is coordinated with the Security Plan (a section of the Master Project Plan). The sub-sections provide additional detail on key elements of the solutionís security.]

<<Begin text here>>

 

Security Design Implications

[Description: The Security Design Implications section identifies the specific aspects of the design that satisfy the solutionís security requirements.]

<<Begin text here>>

 

Security Implementation Issues

[Description: The Security Implementation Issues section identifies any issues that arise from the solutionís design that impact security implementation.]

<<Begin text here>>

 

Security Operational Support Considerations

[Description: The Security Operational Support Considerations section defines how the design will influence the solutionís managerial and operational support processes. The specific security controls are defined in the Security Plan.]

<<Begin text here>>

 

Installation and Setup

[Description: The Installation and Setup section describes the strategy for the solutionís installation. This information may also be found in the Deployment Plan. The sub-sections specify the required hardware and software.]

<<Begin text here>>

 

Hardware Requirements

[Description: The Hardware Requirements section identifies the hardware components that will be required for installation. The hardware installation procedures can be found in the Deployment Plan.]

<<Begin text here>>

 

Software Requirements

[Description: The Software Requirements section identifies the software components that will be required for installation. The software installation procedures can be found in the Deployment Plan.]

<<Begin text here>>

 

Un-Installation

[Description: The Un-Installation section describes the strategy for the solutionís removal from its deployment environment.]

<<Begin text here>>

 

Design for Deployment

[Description: The Design for Deployment section describes the technical specifications that will assist in executing the solutionís deployment. These are design considerations based on the solutionís current and future environment. This information should not describe the deployment process (as that is the content of the Deployment Plan).]

<<Begin text here>>

 

Design for Migration

[Description: The Design for Migration section describes the technical specifications that will assist in executing the solutionís migration. These are design considerations based on the solutionís current and future environment. This information should not describe the migration process (as that is the content of the Migration Plan).]

<<Begin text here>>

 

Design for Integration

[Description: The Design for Integration section describes the technical specifications that will ensure the solutionís integration and interoperability with surrounding solutions/systems. These are design considerations based on the solutionís current and future environment.]

<<Begin text here>>

 

Accessibility Support

[Description: The Accessibility Support section describes the design elements that meet handicap and accessibility requirements.]

<<Begin text here>>

 

Multi-language Support

[Description: The Multi-Language Support section describes the design elements that meet multi-language requirements.]

<<Begin text here>>

 

Design for Supportability

[Description: The Design for Supportability section describes the technical specifications that will assist in the solutionís supportability. These are design considerations based on the solutionís current and future environment. This information should not describe the supportability process (as that is the content of the Support Plan).

Justification]

<<Begin text here>>

 

Logging/Eventing

[Description: The Logging/Eventing section describes how logging will occur within the solution.]

<<Begin text here>>

 

Error Messages

[Description: The Error Messages section describes how error messages will be created and communicated within the solution.]

<<Begin text here>>

 

Diagnostic Tools

[Description: The Diagnostic Tools section describes how diagnostic tools are integrated into the solution and how they will function.]

<<Begin text here>>

 

Recovery from Corruption/Error Messaging

[Description: The Recovery from Corruption/Error Messaging section describes how the solution will recover from corruption events.]

<<Begin text here>>

 

Issues

[Description: The Issues section identifies any unresolved issues that are related to the solutionís physical design. This information should list the issue and its implications to the design.]

<<Begin text here>>

 


 

Appendix