About Deployment Design

Deployment design begins with the deployment scenario created during the logical design and technical requirements phases of the solution life cycle. The deployment scenario contains a logical architecture and the quality of service (QoS) requirements for the solution. You map the components identified in the logical architecture across physical servers and other network devices to create a deployment architecture. The QoS requirements provide guidance on hardware configurations for performance, availability, scalability, and other related QoS specifications.

Designing the deployment architecture is an iterative process. You typically revisit the QoS requirements and reexamine your preliminary designs. You take into account the interrelationship of the QoS requirements, balancing the trade-offs and cost of ownership issues to arrive at an optimal solution that ultimately satisfies the business goals of the project.

Project Approval

Project approval occurs during the deployment design phase, generally after you have created the deployment architecture. Using the deployment architecture and possibly also implementation specifications described below, the actual cost of the deployment is estimated and submitted to the stakeholders for approval. Once the project is approved, contracts for completion of the deployment are signed and resources to implement the project are acquired and allocated.

Deployment Design Outputs

During the deployment design phase, you might prepare any of the following specifications and plans:

• Deployment architecture. A high-level architecture that depicts the mapping of a logical architecture to a physical environment. The physical environment includes the computing nodes in an intranet or Internet environment, processors, memory, storage devices, and other hardware and network devices.

• Implementation specifications. Detailed specifications used as a blueprint for building the deployment. These specifications provide specifics on the computer and network hardware to acquire and describe the network layout for the deployment. Implementation specifications also include specifications for directory services, including details on a directory information tree (DIT) and the groups and roles defined for directory access.

• Implementation plans. A group of plans that cover various aspects of implementing an enterprise software solution. Implementation plans include the following:

  • Migration plan. Describes the strategies and processes for migrating enterprise data and upgrading enterprise software. The migrated data must conform to the formats and standards of the newly installed enterprise applications. All enterprise software must be at correct release version levels to interoperate.

  • Installation plan. Derived from the deployment architecture, specifies hardware server names, installation directories, installation sequence, types of installation for each node, and the configuration information necessary to install and configure a distributed deployment.

  • User management plan. Includes migration strategies for data in existing directories and databases, directory design specifications that takes into account replication design specified in the deployment architecture, and procedures for provisioning directories with new content.

  • Test plan. Describes the procedures for testing the deployed software, including specific plans for developing prototype and pilot implementations, stress tests that determine the ability to handle projected loads, and functional tests that determine if planned functionality operates as expected.

  • Roll-out plan. Describes the procedures and schedule for moving the implementation from a planning and test environment to a production environment. Moving an implementation into production usually occurs in various phases. For example, the first phase might be deploying the software for a limited group of users and increasing the user base with each phase until the entire deployment is complete. Phased implementation can also include scheduled implementation of specific software packages until the entire deployment is complete.

  • Disaster recovery plan. Describes procedures on how to restore the system from unexpected system-wide failures. The recovery plan includes procedures for both large scale and small scale failures.

  • Operations plan (Run Book). A manual of operations that describes monitoring, maintenance, installation, and upgrade procedures.

  • Training plan. Contains processes and procedures for training operators, administrators, and end users on the newly installed enterprise software.

Factors Affecting Deployment Design

Several factors influence the decisions you make during deployment design. Consider the following key factors:

• Logical Architecture. The logical architecture details the functional services in a proposed solution and the interrelationships of the components providing those services. Use the logical architecture as a key to determining the best way to distribute services. A deployment scenario contains the logical architecture paired with quality of service requirements (described below).

• Quality of service requirements. The quality of service (QoS) requirements specify various aspects of a solution’s operation. Use the QoS requirements to help develop strategies to achieve performance, availability, scalability, serviceability, and other quality of service goals. A deployment scenario contains the logical architecture (described previously) paired with quality of service requirements.

• Usage analysis. Usage analysis, developed during the technical requirements phase of the solution life cycle, provides information on usage patterns that can help estimate load and stress on a deployed system. Use the usage analysis to help isolate performance bottlenecks and develop strategies to satisfy QoS requirements.

• Use cases. Use cases, developed during the technical requirements phase of the solution life cycle, lists distinct user interactions identified for a deployment, often identifying the most common use cases. Although the use cases are embodied in the usage analysis, when assessing a deployment design you should refer to the use cases to make sure that they are properly addressed.

• Service level agreements. A service level agreement (SLA) specifies minimum performance requirements, and when those requirements are not met, the level and extent of customer support that must be provided. A deployment design should easily meet the performance requirements specified in a service level agreement.

• Total cost of ownership. During deployment design you analyze potential solutions that address the QoS requirements for availability, performance, scalability, and others. However, for each solution you consider, you must also consider the cost of that solution and how that cost impacts the total cost of ownership. Make sure that you consider the trade-offs embodied by your decisions and that you have optimized your resources to achieve business requirements within business constraints.

• Business goals. Business goals are stated during the business analysis phase of the solution life cycle and include the business requirements and business constraints to meet those goals. Deployment design is ultimately judged by its ability to satisfy the business goals.