SWEN 5135 Configuration Management

Deployment Plan

The Deployment Plan describes how the product will be transitioned to the user community.

Topics

• Identifying compatibility, conversion and migration strategies
• Determining the deployment schedule
• Determining the deployment sequence
• Determining user training needs

Identifying compatibility, conversion and migration strategies

If the system will replace an existing system, compatibility, conversion, and migration issues must be addressed.  Specifically:

• Data from an existing system must be carried forward (and possibly converted in format) for the new system.
• Existing user interfaces (screen formats, commands, etc) must be supported in the new system.
• All existing application programming interfaces (APIs) must be maintained.
• Migration from the existing system to the new one must not disrupt end user service for more than a pre-determined amount of time (varies depending on the business).
• The new system must be capable of operating in parallel with the old system during the migration period.
• There must be a capability to fall back to the old system, if needed, during the first two weeks of operation.
• Old archive data may need to be processed on the new system. If it is cryptographically protected, then the encryption keys will need special consideration when migrating.

The strategies chosen to address these issue will require appropriate support in the architecture and design of the system

Determining the deployment schedule

Transitioning a system into a production environment requires planning and preparation.   Technical factors to be considered include:

• Users of the system may need to be trained.
• The production support environment must be prepared and production support staff must be trained and ready to support the system.
• Production support procedures, including backup, recovery, and problem resolution must be established.

Business factors influencing the deployment schedule include:

• There may be specific business objectives which require the system to be deployed by a specific date; failure to meet this date may significantly reduce the value of the system.  (Note: existence of these kind of requirements introduce risks which should be identified in the Artifact: Risk List and should be mitigated in the Artifact: Risk Management Plan.  Potential changes to the costs and benefits of the system should be noted in the Artifact: Business Case.)
• There may be time periods during which deployment of the system is impossible due to business or operating conditions, including but not limited to ends of financial reporting periods or periods during which the system cannot be shut down. 

  Workload peaks and other factors in the existing systems and processes might prevent deployment at certain times. For example:

  • Larger processing volumes: weekly, monthly or yearly peaks
  • Regular maintenance cycles for hardware or software - impacts both systems availability and staff
  • Peak holiday periods
  • Planned one-off disruptions due to hardware upgrades or introduction of new systems
  • Planned reorganizations
  • Facilities changes.
• Some systems can never be shut down (network and telephony switches, for example); these systems may require new versions of the system to be deployed while the previous version is still running.  Upgrading a high-availability system usually requires special architectural considerations, which must be documented in the Artifact: Software Architecture Document.

Determining the deployment sequence

Some systems must be deployed incrementally, in parts, due to timing or availability issues.  If the system cannot be deployed all at once, the order in which components must be installed, and the nodes on which they are installed, must be determined.  Common deployment scheduling patterns include:

• Geographically - by area
• Functionally - by application
• Organizationally - by department or job function

When an application is deployed over a period of time, issues which need to be resolved include:

• the software must be able to run in a partial configuration
• different versions of the software must be capable of coexisting
• it must be possible to revert back to a prior version of the system in the event that problems with the new system are detected

These capabilities cannot be achieved without focused architectural effort and should be documented in the Artifact: Software Architecture Document.

Determining user training needs

For each category of user, including administration, operators, and end users, identify:

• What types of IT systems they use at the present. If this system will bring the first use of IT to any users, either within or external to the organization, flag this as a special requirement that will merit special attention.
• What new functions will be brought to them by this system.
• In broad terms, what their training needs will be.
• What requirements exist for National Language Support (NLS)

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process