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 |
|
Ó 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
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 |
|
Environment Constraints, and
Assumptions. 4
Hardware Environment
Dependencies. 4
Software Environment
Dependencies. 5
User Services (UI – User
Interface) 5
Component <<Component Name>>
Design. 5
Business Services (Middle-tier
Business Logic) 7
Component <<Component Name>>
Design. 7
Component <<Component Name>>
Design. 9
Authentication/Active Directory/NT
Domain Strategy. 14
Individual Product/Service
Features to be Implemented. 16
Service <<Service Name>>
Configuration. 16
Configuration of
Environment 16
Security Design
Implications. 17
Security Implementation
Issues. 17
Security Operational Support
Considerations. 17
Recovery from Corruption/Error
Messaging. 19
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.}]
[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>>
[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>>
[Description: The Dependencies section identifies the
project, hardware, and software dependencies and resources required to enable
development to begin.]
[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>>
[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>>
[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>>
[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.]
[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>>
[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.).]
[Description: The Behavioral Summary section describes
the expected component
behavior, including a high-level description of services and
value.]
<<Begin text here>>
[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>>
[Description:
The New Application Interfaces section describes the interface names,
public/private methods, arguments and syntax required of all new
interfaces.]
<<Begin text here>>
[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>>
[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>>
[Description:
The Scripting Interfaces section describes all interface names, public/private
methods, arguments, and syntax required.]
<<Begin text here>>
[Description:
The Registry Impact – Configuration and Settings section describes the registry
keys created, default configuration, and values.]
<<Begin text here>>
[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>>
[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>>
[Description:
The Component Management Issues section describes any unique aspects of the
component design.]
<<Begin text here>>
[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>>
[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.).]
[Description: The Behavioral Summary section describes
the expected component
behavior, including a high-level description of services and
value.]
<<Begin text here>>
[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>>
[Description:
The New Application Interfaces section describes the interface names,
public/private methods, arguments and syntax required of all new
interfaces.]
<<Begin text here>>
[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>>
[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>>
[Description:
The Scripting Interfaces section describes all interface names, public/private
methods, arguments, and syntax required.]
<<Begin text here>>
[Description:
The Registry Impact – Configuration and Settings section describes the registry
keys created, default configuration, and values.]
<<Begin text here>>
[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>>
[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>>
[Description:
The Component Management Issues section describes any unique aspects of the
component design.]
<<Begin text here>>
[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>>
[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.).]
[Description: The Behavioral Summary section describes
the expected component
behavior, including a high-level description of services and
value.]
<<Begin text here>>
[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>>
[Description:
The New Application Interfaces section describes the interface names,
public/private methods, arguments, and syntax required of all new
interfaces.]
<<Begin text here>>
[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>>
[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>>
[Description:
The Scripting Interfaces section describes all interface names, public/private
methods, arguments, and syntax required.]
<<Begin text here>>
[Description:
The Registry Impact – Configuration and Settings section describes the registry
keys created, default configuration, and values.]
<<Begin text here>>
[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>>
[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>>
[Description:
The Component Management Issues section describes any unique aspects of the
component design.]
<<Begin text here>>
[Description: The Database Design section defines the
complete database strategy.]
<<Begin text here>>
[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>>
[Description:
The Stored Procedures section describes each stored procedure name, its
functionality, parameters/arguments, and transactional
support.]
<<Begin text here>>
[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>>
[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>>
[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>>
[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.]
[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>>
[Description: The Intranet Communication section describes
the server and services
communication strategy within the firewall boundaries for the
solution.]
<<Begin text here>>
[Description: The Services section itemizes all intranet communication product
services to be implemented within the solution.]
<<Begin text here>>
[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>>
[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>>
[Description: The Security section lists the security configuration
options/requirements specific to intranet communication.]
<<Begin text here>>
[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>>
[Description: The Services section itemizes all Internet communication product
services to be implemented within the solution.]
<<Begin text here>>
[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>>
[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>>
[Description: The Security section lists the security configuration
options/requirements specific to Internet communication.]
<<Begin text here>>
[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>>
[Description: The Services section itemizes all extranet communication product
services to be implemented within the solution.]
<<Begin text here>>
[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>>
[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>>
[Description: The Security section lists the security configuration
options/requirements specific to extranet communication.]
<<Begin text here>>
[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>>
[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>>
[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.]
<<Begin text here>>
<<Begin text here>>
<<Begin text here>>
[Description: The Name Resolution
section describes the method for resolving host (server) and client names on the
networks (DNS/WINS, etc.).]
<<Begin text here>>
<<Begin text here>>
[Description: The Remote Access section describes
how the feature(s) work when connected via remote access or slow
links.]
<<Begin text here>>
[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>>
[Description: The Server Placement
section describes the guidelines for placing servers, both centrally or
remote.]
<<Begin text here>>
[Description: The Server Sizing section describes
the guidelines for configuring servers.]
<<Begin text here>>
[Description: The Administrative Model
section describes how the servers and clients will be
administrated.]
<<Begin text here>>
[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>>
[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>>
[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>>
[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>>
[Description: The Security Design
Implications section identifies the specific aspects of the design that satisfy
the solution’s security requirements.]
<<Begin text here>>
[Description: The Security
Implementation Issues section identifies any issues that arise from the
solution’s design that impact security implementation.]
<<Begin text here>>
[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>>
[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>>
[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>>
[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>>
[Description: The Un-Installation
section describes the strategy for the solution’s removal from its deployment
environment.]
<<Begin text here>>
[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>>
[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>>
[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>>
[Description: The Accessibility Support
section describes the design elements that meet handicap and accessibility
requirements.]
<<Begin text here>>
[Description: The Multi-Language Support
section describes the design elements that meet multi-language
requirements.]
<<Begin text here>>
[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>>
[Description: The Logging/Eventing
section describes how logging will occur within the
solution.]
<<Begin text here>>
[Description: The Error Messages section
describes how error messages will be created and communicated within the
solution.]
<<Begin text here>>
[Description: The Diagnostic Tools
section describes how diagnostic tools are integrated into the solution and how
they will function.]
<<Begin text here>>
[Description: The Recovery from
Corruption/Error Messaging section describes how the solution will recover from
corruption events.]
<<Begin text here>>
[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>>