Chapter 3: Planning Phase: Creating Your Solution Design and Architecture, Project Plans, and Project Schedule

Article
12/05/2007

This chapter provides the background and technical information required to complete the Planning Phase of a migration project.

Introduction to the Planning Phase

The Planning Phase is the time when the project team translates the initial vision/scope from the Envisioning Phase into practical plans on how to achieve it. The purpose of the Planning Phase is to define the solution in detail along with the approved project plan and schedule. This work includes creating a functional specification, developing the solution architecture and design, and preparing cost estimates. Team members draw upon their expertise to create detailed individual plans, such as the development plan, test plan, and deployment plan, as well as schedules for all aspects of the project. Program Management combines these individual plans and schedules and synchronizes them to create the master project plan and schedules. The Planning Phase culminates in the Project Plans Approved Milestone. Passing this milestone indicates that the customer, the project team, and all stakeholders agree on the details of the plans, including what will be built, how it will be built, when it will be delivered, and what it will cost.

Planning Phase Tasks

The major migration tasks conducted during the Planning Phase are summarized in the following list. They will be described in more detail in the subsequent sections.

Developing the solution design and architecture. The development team begins the design process with the solution design and architecture and culminates it with a design document that becomes part of the functional specification.
Validating the technology. The development team also validates technologies to ensure that they meet the business needs for the specific solution.
Creating the functional specification. The project team and Program Management Role create a functional specification that describes the solution requirements, the architecture, and the detailed design for all the features. This represents the contract between the project team and customer.
Developing the project plans. The Program Management Role and the various teams that make up the project team develop a collection of plans to define the tasks for all six MSF team roles, and Program Management consolidates them into a master project plan.
Creating the project schedules. The Program Management Role and the various teams create milestone-driven schedules for each individual team role, and Program Management consolidates them into the master project schedule.
Setting up the development and test environment. The development and test teams create development and testing environments that are independent of the production environment to develop and test the solution.
Close the Planning Phase. The project team completes the Planning Phase with the approval process for the Project Plans Approved Milestone.

Note Although listed sequentially, many of these activities can be performed concurrently.

Planning Phase Deliverables

The Planning Phase activities culminate in a major milestone, the Project Plans Approved Milestone. By the end of the Planning Phase, the project team and all major stakeholders (other members of the organization who will be affected by the project) should have agreed upon the functional specification, technology for the solution, and project plans and schedule. These deliverables include:

A technology validation-complete document that:
- Documents the current environment.
- Develops and tests the key features in the solution with a proof of concept.
- Documents all the potential issues and their resolution.
A functional specification document that:
- Describes requirements of all the components of the solution.
- Describes solution design and architecture of the components.
- Provides quantitative specifications about performance measures, database capacity, and concurrent usage and security measures.
A master project plan of the solution that:
- Contains individual plans for various roles.
- Guides the project completion as per the functional specification.
A master project schedule that:
- Integrates all the schedules along with release dates.
- Creates awareness about project priorities.
A risk management document that:
- Identifies the potential risks and mitigation strategies.
An instruction document on setting up the development and test environments that:
- Creates a proper development and testing environment for the solution without affecting the production system.
- Identifies the hardware and infrastructure requirements for the environment.

Together, these deliverables comprise a high-level design description and plan of the project that form the basis for the subsequent phases. Therefore, the functional specification document, especially, must be viewed as a living document that keeps changing, subject to change control. The deliverables may undergo numerous iterations before the project team, the customers, and the stakeholders reach a final consensus.

Note For more detailed discussions on how these tasks and deliverables can be approached and the responsibilities assigned for them, refer to the Unix Migration Project Guide (UMPG) at https://www.microsoft.com/technet/itsolutions/cits/interopmigration/unix/umpg/default.mspx.

Instructions for setting up the development and test environments are explained in Chapter 4, *“*Planning: Setting Up the Development and Test Environments” of this volume.

Planning Phase Activities

The following sections detail the various activities involved in the Planning Phase of the MSF Process Model and how these activities specifically relate to a migration project.

Developing the Solution Design and Architecture

The development of the solution design and architecture begins with a design process, the results of which become the functional specification. The design process helps identify the project team structure and the team's responsibilities for the upcoming Developing Phase. The foundation of the design process is the vision that the team developed and the business goals that were gathered during the Envisioning Phase. The architectural design describes how features and functions operate together to form the solution. It identifies the specific components of the solution and their relationships.

The design document contains details of the architecture and the components that go into building the solution. For UNIX-to-Windows migration projects, the solution architecture remains the same; however, to include it in the design document ensures completeness. This helps the team to work in a systematic way—from abstract concepts in the vision/scope document down to specific technical details in the design process. It also helps to maintain the correlation between the requirements and the solution features.

Conceptual Design

The conceptual design stage includes the process of analyzing and prioritizing business and user perspectives of the problem and the solution, and then creating a high-level representation of the solution. This stage helps in mapping the functionality associated with each of the requirements.

A conceptual design is a means to understand the business expectations and application requirements that include both technical and infrastructure requirements in terms of business, user, system, and operational requirements. The design formulates the solution to be developed, keeping in mind the end users and the business requirements. It is therefore essential to answer all questions in the assessment checklist provided with this guide. This helps to assess the current situation and further define the project scope developed during the Envisioning Phase in order to obtain a clear understanding of the functionality required to build the solution.

The conceptual design lays the foundation for developing the solution and addresses the requirements by describing the design and architecture of its components.

For migration projects, the conceptual design is generally identical to the original functionality of the current application or infrastructure component. It is nonetheless important to articulate the existing design in the functional specification for the migration project because the actual concept for the current component may have drifted from its initial conception. Even if that conceptual design has remained constant, it serves as a touchstone for subsequent design phases.

The following example demonstrates what is meant by conceptual design.

Example of a Conceptual Design

Consider an engineering graphics application developed in UNIX that is used by the design staff within an organization. Because of evolving business requirements and a globalized environment, the organization now wants to make use of the capability of its external partners to provide design solutions using the same application.

To achieve this, the application needs to be available on the Microsoft® Windows® platform, which most of its suppliers have already standardized on.

Migrating this application to the Windows platform enables it to be shared with the partners, resulting in an increased degree of collaboration between users who use the application, both within the organization and outside.

The conceptual design should document any unique requirements that would arise in this new environment and verify that the proposed solution architecture caters to these requirements.

Logical Design

During the logical design stage, each part of the conceptual design is assigned to a specific role within the architecture of the solution. It provides a clear view of the solution from the functional perspective. A logical design identifies and defines all the objects and their behaviors, attributes, and relationships within the scope of the solution. The application design is split into three levels: presentation, business, and the data layer. For a migration project, you must document the existing logical design as well as the logical design of the migrated application or infrastructure component and emphasize the areas of change if applicable. It is also important to show how the migration project affects the other components outside the scope of the project.

Example of Logical Design

Continuing with the same engineering application example, the logical design documents the existing as well as the new architectural components required to realize the conceptual design. The presentation layer can be achieved by a Windows user interface (UI) instead of the existing X-Motif–based user interface. The communication layer can be achieved by Winsock or .NET messaging in place of the existing UNIX sockets calls.

It may also be necessary to show how the migrated applications interact with other components outside the scope of the migration project. For example, it is possible for applications on the partner’s side to exchange data with the migrated application on Windows.

Physical Design

The physical design of the solution identifies the pieces from the logical design that must fit into the physical architecture. The physical design identifies the physical infrastructure architecture and topology. It creates a set of physical design models, including the component’s design, UI design, and a physical database design for the applications. The physical design should include anticipated metrics to assess performance goals, uptime goals, and milestones for writing the solution code. For example, the physical design might include metrics for transaction time and performance requirements for the transactions before deployment. Production metrics for the particular deployment scenarios must also be established.

The physical design is a complete implementation design, in the form of a technical specification, that the development team uses to build the solution. For a migration project, the physical design should also include the process of implementing the infrastructure and the step-by-step details of how to deploy the migrated application, keeping in mind the current milestones of the application. It must also cover how the new implementation satisfies the business requirements without violating ongoing service level agreements (SLAs).

Example of Physical Design

The physical design of the application might describe which components in each of the layers (presentation, business, and data) need to be changed in one of the following ways:

Ported to recompile and fix problems that arise.
Rewritten if there is no corresponding library or component available on Windows.
Replaced if an equivalent library is available in Windows.
Purchased if the library or component is to be bought from third-party vendors.

It might also provide a detailed mapping of the source UNIX architecture to the target Windows architecture, where each component/library of the UNIX application is mapped to one that provides equivalent functionality on Windows.

Validating the Technology

Often, in tandem with the design process, your team can also validate the technologies being used in the solution. In the technology validation process, the team evaluates the products or technologies to ensure that they work according to the specifications provided by their vendors and that they address the business needs for the specific solution scenario. Validating the technology is an essential step in a UNIX-to-Windows migration project because the tools, software, and hardware in the new Windows environment must work together to produce the same or better effect than that produced in the UNIX environment. For example, if the UNIX application uses a third-party library and if a Windows version of it is also available, it would be a good idea to check if the Windows equivalent of the library works according to the required specifications.

Technical Proof of Concept

After validating the technologies, the team makes an initial attempt at creating a model of the technology that will be implemented. This produces a proof of concept. The initial proof-of-concept model often produces both answers and additional questions for the team about the issues that might arise with the technology during the Developing Phase. This information helps in the risk management process and identifies overall design changes that must be incorporated into the specifications.

The various libraries or modules in the UNIX application can be listed in the functional specification document, as shown in the following proof-of-concept identification table for a sample banking solution application.

Table 3.1. Sample Proof-of-Concept Identification

Name of Library or Module	Area or Layer of the Application	Functionality Covered	Prototype Required (Y/N)?
LoanInterestCalLib	Loans–Business Layer	Interest calculating routines	N
AuthenticationLib	User Authentication–Business Layer	Secured login routines	N
Super-annuityLib	Retirements–Business Layer	Retirements routines	Y
DataAccessLib	DataAccess Layer	Database routines	Y

In a UNIX-to-Windows migration project, the proof of concept typically addresses such areas as the compatibility and suitability of certain third-party libraries in the Windows environment, the manner in which certain UNIX-environment–specific features are handled in Windows, and how the performance of the application in the Windows environment will change. It may even involve the porting of a small portion of the application to confirm the migration methodology. If possible, steps should be taken to create a reusable prototype, which can be used again in the actual migration phase.

The following are examples of proof of concepts:

Porting of a small portion of the communications library in the UNIX application to Windows in order to establish the communication model between the migrated Windows client and server.
Porting of a text-based library of the UNIX application, which uses GLX (OpenGL Extensions) for character rendering to Windows and uses WGL (Wiggle) to compare the rendering speed of characters.

Baselining the Environment

The team must also conduct an audit of the as-is production environment in which the solution is now operating. Information is collected on server configurations, network, desktop software, and all relevant hardware. This baseline allows for the team to account for any changes that might be required or design issues that might cause the solution to be at risk. This baselining step is critical to the success of a migration project.

Interim Milestone: Technology Validation Complete

At this point, the team has confirmed the technologies to be used and should be well versed with the technical issues in order to move forward with creating the functional specification. The team also validates the technology, considering the implementation of the features from the business perspective. When you reach this milestone, you are ready to create the functional specification for the solution.

Creating the Functional Specification for the Solution

The functional specification document is a technical description of the solution and represents the contract between the customer and the project team. It is the basis for building project plans and schedules for the migration project. The program manager takes the lead in creating the functional specifications, with input from the role leads regarding their areas of responsibility. During the Planning Phase, the functional specification document is baselined and, after a formal review from the project manager, is taken as the final document. Otherwise, a change document is prepared for the functional specification.

The Solution Feature Set

A basic functional specification document must include the following:

A summary of the vision/scope document as agreed upon and refined, including background information to place the solution in a business context.
Any additional user and customer requirements beyond those already identified in the vision/scope document.
The solution design (including conceptual, logical, and physical designs).
Specifications of the components that will be a part of the solution.

Interim Milestone: Functional Specification Baselined

The functional specification is maintained as a detailed description of the various solution components and how the solution will look and operate. The team baselines this functional specification and formally tracks the changes based on the customer’s approval of the changes. The functional specification is the basis for building the master project plan and schedule. When you reach this milestone, you are ready to develop plans to execute the project.

Developing the Project Plans

During the Planning Phase, you must map the requirements to the conceptual, logical, and physical designs, as well as plan for the future phases of the project. Plans need to be developed for developing or migrating, stabilizing, deploying, and operating the system, and also for other aspects of the project such as the budget, team communication, facilities, and purchasing. Depending on the size and complexity of the project, the number of plans can vary. The essential plans that are a part of the master project plan are discussed in this section. The program manager is responsible for creating the master project plan components in consultation with various teams. The master project plan consolidates the feature team and role plans and guides the project to completion, as defined by the functional specification. It is a key Planning Phase deliverable.

The benefit of having a plan that breaks into smaller plans is that it:

Facilitates concurrent planning by various team roles.
Keeps accountability clear because specific roles are responsible for various plans.

The benefit of presenting these plans as one Master Project Plan is that it:

Facilitates synchronization into a single schedule.
Facilitates reviews and approvals.
Helps identify gaps and inconsistencies.

Note Sample MSF deliverables, templates, and white papers are available at https://www.microsoft.com/technet/itsolutions/msf/default.mspx.

The following table lists the various essential plans that are part of a master project plan, describes the purpose of each plan, and names who is responsible for creating the corresponding plan.

Table 3.2. Preparing the Master Project Plan

Name of Plan	Purpose of Plan	Responsibility
Budget and Purchasing Plan	To establish the estimated cost of migration and determine what resources and infrastructure requirements will be required for the migration.	Program Management team
Solution Development Plan	To validate the feasibility of the migration strategy and identify requirements for environment readiness.	Development team
Solution Testing Plan	To ensure the quality of the migrated solution, test plan, and test methodology.	Test team
Pilot Deployment Plan	To ensure smooth deployment at production.	Release Management team
Production Deployment Plan	To specify the deployment instructions on the production computer configuration.	Release Management team
User Operations Training Plan	To ensure that the UNIX users are comfortable with the migrated Windows applications.	Release Management team
Security Plan	To make the migrated application as secure as it was on UNIX.	Development team and Release Management team
Communications Plan	To define the communication strategy with the customer.	Product Management team

Budget and Purchasing Plan

Adequate financing is crucial for a project to survive, and therefore a budget plan is important. You may get into a situation where you need resources that your project budget cannot accommodate. The needs and demands of all the phases of the project must be taken into account when planning the budget.

The budget plan must include the following information:

Software costs, including those of the operating system, development tools, and management tools.
Hardware costs, including those of computers, power supplies, racks, and cables.
Personnel costs, including those for executing the migration and maintaining the system post-migration.
Cost of training resources, including those associated with developers, administrators, and end users.
Cost of vendor support for software, hardware, and network.
Miscellaneous costs, such as those for travel and shipping.

The purchasing plan includes (but is not limited to) the following information:

Equipment required for the setup, such as racks, power points, and uninterruptible power supply (UPS).
Test setup resources.
Systems required for the setup.

Solution Development Plan

The development plan describes the solution development process for the project, in addition to the tasks to create and assemble the components of the solution. A development plan for a UNIX-to-Windows migration project should include (but not be limited to) the following information:

How to set up an Interix or Win32/Win64 or .NET development environment for the migration.
How to set up the test environment to migrate the application code.
The different components of the application and an indication of the components that will be migrated and the ones that will be replaced.
After the various scripts, modules, and tools of the UNIX system have been successfully migrated to Windows, they need to be integrated into the Windows environment. They must work together with other dependent applications. This development must precede the development of the application. Integration activities must be added to the existing development plan.
A list of the porting methodologies that can be used for the application. (Porting methodologies are discussed in detail in the build volumes [Volumes 2, 3, and 4] of the guide.)
Configuration management is the process used to control, coordinate, and track code, requirements, documentation, issues, change requests, tools, changes affected, and the people making the changes. Configuration management activities must be added to the existing development plan.

Solution Testing Plan

The testing team tests the migrated application. Testing can begin before the entire development is complete. It must include tests for security, scalability, and performance of the application, along with the functionality tests of the migrated application.

A testing plan describes the strategy and approach that is used to plan, organize, and manage the testing activities in a project. It identifies the testing objectives, methodologies, tools, expected results, responsibilities, and resource requirements. The Test Role is responsible for creating the test plan. The test plan must include (but is not limited to) the following information:

Manual procedures or script to test if the setup works.
Testing procedures (testing methodology).
Test cases to test the functionality of the application.
Test cases to test the interaction with other applications.
Expected results compared with the existing UNIX application functionality.
Assumptions made prior to testing.
Bug reporting and tracking mechanisms.
Plans to improve the performance of the application and the application infrastructure.

Pilot Deployment Plan

The pilot deployment plan addresses the initial deployment of the solution into the production environment. The pilot deployment plan includes (but is not limited to) the following information:

Pilot participant profiles and their selection process.
The number of pilot builds and the number of participants in them.
The procedure for the pilot deployment.
Backup and recovery mechanisms in case of deployment failures.
Mechanisms to gather feedback on the pilot application.

Production Deployment Plan

The production deployment plan addresses the deployment of the migrated application based on various scenarios that you have encountered and the best practices that you have drawn up for deploying the pilot application. The production deployment plan must include (but is not limited to) the following information:

Details of the deployment process for the operating system.
The modules of the migrated application to be deployed.
The tools to be used for the deployment of the migrated application and other software.
The deployment procedure.
Backup and recovery mechanisms in case of deployment failures.

User and Operations Training Plan

The user and operations training plan focuses on the process that the users and their operations should follow to make a successful transition from the UNIX environment to the new Windows environment. It includes details on the process that the Release Management Role should follow to coordinate with the current operations team to ensure a smooth migration and rollover. The user and operations training plan includes (but is not limited to) the following information:

Details of the training needs of the existing users, which will enable them to work on the migrated application and the Windows environment.
Details on making software and hardware inventories.
Details on network administration and security administration in the new environment.
Backup procedure details for the new system.
Details on monitoring the new system's performance on a daily basis.

Security Plan

Security is often overlooked during the Planning Phase. The importance of security is only realized when you begin working on the system. A security plan includes (but is not limited to) the following information:

Details of various roles and users who may access the application.
Types of access rights given to various user groups.
Response measures for a possible security breach.
Physical security plans.
Details on how users can access the setup location.
Details on the roles that can access the application for infrastructure maintenance.

Communications Plan

Communication between various roles and with the customer is very important for the success of a project. Most delays and wrong executions are usually due to a communication gap. A communications plan should contain (but is not limited to) the following information:

Procedures for escalating issues.
Procedures for managing status updates.
Types of issues and the roles that will handle communication regarding the issues.

A service level agreement (SLA) can be drawn up at the start of the project. This lists the communication channels and the levels of escalation for each.

Interim Milestone: Master Project Plan Baselined

At this point, the team has rolled up all initial drafts of the plans required to create estimates for the time required to fulfill these project plans.

Creating the Project Schedules

The UNIX Migration Project Guide (UMPG), a companion to this guide, contains most of the information that you will need to develop a schedule for your migration project. Some important points to consider while creating the project schedules are as follows:

The individual schedules must fit into the overall migration project schedule.
When drawing up project schedules, it is best to define the milestones early in order to establish the proof of concept. In a UNIX-to-Windows migration project, the proof of concept provides valuable inputs for overall project estimations by giving a realistic picture of the expertise and the time required to complete the application by extrapolating on the proof-of-concept time and the overall cost of the project.
You may want to treat the application infrastructure migration separately from application migration. If you do, you may have parallel milestones. In a UNIX-to-Windows migration project, the effort required to procure the hardware and software is often underestimated. Effort estimations are often based solely on the size of the application, which results in an inaccurate estimate. A project schedule must therefore include the hardware and software procurement time, the time required for the initial setup of the infrastructure, and the time needed to establish the proof of concept.
The project schedule must be drawn up by the Program Management Role in consultation with representatives of all the roles because this will provide estimates for all areas of the project.

Interim Milestone: Master Project Schedule Baselined

At this point, the goal for the schedule should be set. It creates awareness about the project’s priorities and contributes to a sense of ownership by all the project’s contributors.

Interim Milestones

This chapter discussed the major tasks of the Planning Phase (with the exception of setting up the development and test environments and closing the Planning Phase). The key interim milestones that accompany the activities performed in this chapter are:

Technology Validation Complete
Functional Specification Baselined
Master Project Plan Baselined
Master Project Schedule Baselined

The next chapter discusses setting up the developing and test environments as part of the Planning Phase and their importance in improving the productivity of the development team.