Chapter 3 — Planning Phase: Overview

Article
12/05/2007

Published: June 21, 2004 | Updated: October 29, 2004

Introduction and Goals

This is the phase of a project when the initial vision is translated into practical plans for how to achieve it. The primary goals for the Planning Phase are to create the solution architecture and design, the functional specification, the project plans, and the project schedule. The solution design is articulated as a concept, as a logical system, and as physical components (the conceptual design, logical design, and physical design). Team members draw upon their expertise to create individual plans in all areas of the project, ranging from security to budget to deployment, and the role of Program Management rolls them up into the master project plan. Likewise, individual schedules are combined to become the master project schedule.

As for most planning activities, communication among all the involved parties is critical for smooth coordination and for achieving consensus on decisions. Keep in mind that deliverables may need to undergo numerous iterations before agreement can be reached between the project team and the customer and stakeholders.

The phase concludes when the project team agrees that the plans are sufficiently well-defined to proceed with development, and the team, business sponsor, and key stakeholders approve the master project plan and schedule, usually at a milestone meeting. The formal conclusion is marked by the second major milestone, Project Plans Approved.

The following list identifies the tasks, and their primary owners, that must be completed to meet the milestone.

Assess the current database system (Development/Product Management).

The team begins by assessing the current environment with surveys distributed to key resources in the current organization. A physical assessment of the databases to be migrated is then done by using the Sybase Migration Toolkit. This assessment should include the current security measures, the entire functionality of the system, its performance, and any known problems and issues.
Develop the solution design and architecture (Development).

The 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.
Validate the technology (Development).

The team must ascertain the viability of any proposed solution and ensure that all technological challenges can be met.
Create the functional specification (Program Management/Product Management).

The functional specification describes the functionality of the solution to be built and serves as a contract between the team and the customer on what will be delivered. Project plans and schedules will be based on it.
Develop the project plans (Program Management).

The team will need to write individual plans for development, test, training, deployment, and support that focus more on how things will be done than on what needs to be done. Program Management will consolidate these plans into the master project plan. The master project plan is a roll-up of all of the plans, and it includes strategic items such as the approach, dependencies, and assumptions for the solution.
Create the project schedules (Program Management).

The team creates the master project schedule, which consists of milestone-driven schedules developed by each of the individual team roles when planning their respective activities.
Set up the development and test environments (Development/Test).

Unlike other Planning Phase activities that primarily involve decision making and recording, this task has a physical, hands-on aspect. It is one of the last tasks to accomplish before development can begin. The design of the setup will depend, of course, upon the solution design that the team has constructed during this phase. The development and test environments should be independent of the production environment. The configuration management system should be fully implemented during this task, with baseline versions of all documents and source code established.

Note See the job aids for templates that can help in creating many of the planning deliverables referred to in the preceding list. The job aids are available in the Job Aids folder in the download version of this guide.

Guidance for accomplishing the tasks called for in the Planning Phase is too extensive to contain in one chapter. This chapter addresses the first step in planning —assessment — an activity that underpins all subsequent work in creating the solution design, functional specification, and project plans for both the database and client migrations. It also describes the solution design process and explains how the conceptual design, logical design, and physical design are developed successively.

Guidance for the remainder of the planning activities has been divided into five additional chapters, as follows:

Chapter 4 addresses database migration and covers the solution design, functional specification, and technology validation for database migration aspect of the project.
Chapter 5 addresses client migration and covers the solution design, functional specification, and technology validation for the client migration part of the project.
Chapter 6 covers the creation of the development and test environments.
Chapter 7 discusses using the Sybase Migration Toolkit to automate the assessment of existing Sybase databases, a final step in the assessment process.
Chapter 8 discusses creating the project plans that will be rolled up into the master project plan.

Team Focus during the Planning Phase

The following table is repeated from the UNIX Migration Project Guide to help project team members quickly identify which material in the Planning Phase chapters is most relevant to their role. The primary team role driving the Planning Phase is the Program Management Role.

Table 3.1: Role Cluster Focuses and Responsibilities in Planning Phase

Role Cluster	Focus and Responsibility
Product Management	Conceptual design; business requirements analysis; communications plan
Program Management	Conceptual and logical design; functional specification; master project plan and master project schedule; budget
Development	Technology evaluation; logical and physical design; development plan/schedule; development estimates
User Experience	Usage scenarios/use cases, user requirements, and localization/accessibility requirements; user documentation/training; plan/schedule for usability testing
Test	Design evaluation; testing requirements; test plan/schedule
Release Management	Design evaluation; operations requirements; pilot and deployment plan/schedule

Deliverables for the Planning Phase

The work of the Planning Phase will culminate in three documents:

Functional specification
Master project plan
Master project schedule

The functional specification includes the solution designs for both the database and client application migrations that the team, guided by the vision and constrained by the scope, agreed upon in the vision/scope document.

The master project plan and master project schedule consist of the rolled up individual plans and schedules for each aspect of the work for the project.

Additionally, the development and test environments must be set up before the Planning Phase can end and the Developing Phase can begin.

Assessing the Current Database Environment

To plan for your migration, you must assess your current environment from the business, technological and operations perspectives. Your migration solution will need to embrace the existing environment and take all of your business, technological, and operations requirements into account. A disciplined assessment will be essential to planning the project and staying within the scope agreed upon in the Envisioning Phase.

Specific objectives of the assessment include the following:

Identify the extent to which the specific differences between the Sybase and SQL Server technologies will affect your environment.
Collect information about the current infrastructure to determine the requirements of the new environment and areas of effort that the migration will require.
Provide data to perform the business analysis of the migration and determine the migration strategies available to you.
Help to populate your configuration management and bug-tracking systems for the new database environment.

You should carefully document this process and store collected information in a data repository for reference throughout the Planning Phase.

Understanding the Current Technology Environment

The current environment is comprised of systems and technologies, together with the activities of various groups in the organization that use them. It also includes data that describes the physical and logical aspects of the technology that you will migrate.

One key requirement present in every migration project is that the end result should be at least as good as the original environment. Understanding the current technology in detail will help you to determine if this requirement is met.

Collecting Assessment Data

The job aid questionnaires created for use with this guide provide a profile of the type of information that you will need to plan and implement the solution. These questionnaires are downloaded with the guide and should be located in your project documentation repository for easy access by team members. Every member of the team should be familiar with these questionnaires and assist in identifying who in the organization has the best access to the specific information. You will need to develop a system for distributing the questionnaires, tracking responses, and creating a data repository. If resources are available, using Microsoft® SharePoint™ Portal Server to build a Web-accessible site is a good option. If your organization has a system in place for maintaining an inventory of your technology assets, you may choose to use that resource instead of the questionnaires.

In many cases, certain assessment data is significant or meaningful to a particular role or resource in the organization. Plan for wide distribution of questionnaires, and review all collected data to minimize the possibility of overlooking important implications. Use this opportunity to gather information that helps you understand the relationships between applications and databases.

Figure 3.1 depicts the process for collecting data about the current environment.

Figure 3.1 Collecting data about the current environment

Using the Questionnaires to Collect Data

The questionnaires can be used to gather information about four key aspects of the environment that are involved in a migration: databases, applications, servers, and jobs and scripts.

Database questionnaire. Use this survey to collect information about the database objects that you must address in the migration plan, such as tables, views, and stored procedures, as well as information about the disk space, configuration, workload, availability requirements, dependencies, and a list of applications that use the database. Information to help identify answers to these questions can be found in the system database tables, and in particular SYSOBJECTS, SYSINDEXES and SYSCONSTRAINTS. This job aid is available in the Job Aids folder in the download version of this guide.
Job and scripts questionnaire. Use this questionnaire to collect information about custom UNIX scripts that perform automated tasks, including job type and importance, language, schedule, and dependencies. This job aid is available in the Job Aids folder in the download version of this guide.
Server questionnaire. Use this survey to collect information about the capacity and performance characteristics of the physical servers that host the databases and about the current security provisions. This job aid is available in the Job Aids folder in the download version of this guide.
Application questionnaire. Use this survey to collect information about the purpose and user base for each application, whether it has Windows and SQL Server support, the library used to access data, security issues, and the availability of source code and test scripts. This job aid is available in the Job Aids folder in the download version of this guide.

Key personnel completing the current environment surveys usually include database administrators, IT managers, and development managers. You can publish the questionnaires to target respondents in various ways, such as on a Web site, through e-mail, or even as paper forms — any method that your project structure specifies.

Tracking Questionnaire Results and Consolidating Information

An important outcome of the assessment process is the creation of a central knowledge repository that you can use as the basis for planning decisions, as depicted in Figure 3.2. The distribution of and recording of the results from the questionnaires should be managed by the person or persons in the team who are most capable in each area: database, jobs and scripts, servers or applications. These persons are the champions for each survey area.

Figure 3.2 Tracking questionnaire results

You may need to follow up on the surveys with questions about some of the information and comments that respondents submitted. In addition to tabulating the data, therefore, you will need to ensure that you can identify and communicate with respondents. The type of respondent information that you should consider tracking for each questionnaire sampled includes:

Contact name
Group (within the organization)
Contact location (that is, the respondent's physical location)
Contact phone number
E-mail address
Questionnaire type
Date questionnaire sent to respondent, and date reply received from respondent

Manual Tabulation

For smaller projects, you can consolidate data by storing it in a spreadsheet and creating a summary table to extract the information that will drive the next tasks in your project. Such a summary might look like the following table.

Table 3.2: Sample Consolidated Spreadsheet of Questionnaire Reponses

Database Element	Number
UNIX hosts	4
DB servers	4
Databases	15
Tables	1500
Views	600
Triggers	100
Stored procedures	400
DB-Library applications	3
Open Database Connectivity (ODBC) applications	2
CT-Library applications	4
Total storage allocated	300 GB

Importing Data into a Database

For larger projects, automated tabulation is often necessary. For example, you could create Data Transformation Services (DTS) packages that extract the information from the various source documents (for example, the questionnaires) and insert it into a database. You can then query the information in the database and generate reports.

Using the Collected Data

Although many aspects of a Sybase migration are addressed in this guide, the unique environment of each organization introduces many considerations that cannot be specifically anticipated. These particulars affect the requirements, scope, and processes of a successful migration. The project team needs to translate survey data into a clear understanding of risks, challenges, and issues that may stand in the way of a successful migration. You should expect to spend a significant amount of time discussing each survey and clarifying the relationships between databases and their respective clients and applications, clients or applications that interact with more than one database, databases that you may not need or want to migrate, and so on. The team may have a tendency to rely on the current knowledge base of key players instead of on the survey results and analysis. This approach can be a very fast path to a failure during the migration.

Determining the associations between databases and clients (and applications) is essential for synchronizing the development time frames you will build into the project plans for each component of the solution. Without planning for such synchronization, you introduce the risk of situations in which a database is migrated and ready for integration testing but the client or application that is required to perform the tests has not been migrated or has not even been scheduled for migration. Delays in migration may occur for any number of reasons, but this particular scenario can be potentially disastrous to the success of your project.

Planning Database and Client Application Migration

Information that you collect through the use of the various assessment questionnaires will drive the specific design and implementation choices you need to make, such as:

The process for migrating databases from Sybase to SQL Server.
- Which tools to use — Sybase Migration Toolkit, script editors?
- How will Sybase objects be converted into SQL Server objects?
- How will data be transferred from Sybase to SQL Server?
- How will you verify that all objects and data have been transferred correctly?
Modifying client applications to use SQL Server instead of Sybase.
- Where will client applications run — UNIX or Windows?
- How will client applications connect to SQL Server?
- Will client applications need to be rewritten, recompiled, or reconfigured?
- How will the applications be tested?
Database and application deployment.
- How will the database be deployed? What time is available for switching operations from one database to another?
- How will client applications be deployed?

Chapter 4, "Planning Phase: Database" and Chapter 5, "Planning Phase: Clients" describe planning database and client application migrations in more detail.

Solution Design

Taking into account all of the details listed in the previous section, it should be clear that arriving at all of the correct decisions takes careful planning. Developing a solution design involves looking at the solution from three perspectives: the conceptual design, logical design, and physical design. The following descriptions of these design areas will be put to use in the later chapters on planning.

Conceptual Design

Conceptual design is the first design process of the Planning Phase and defines the problem and solution from the business's and users' points of view. The conceptual design for the migrated database will generally be identical to that developed for the existing Sybase database. Likewise, the conceptual design of migrated client applications should be very similar to the original conceptual design of the original applications. The current environment, however, may represent an evolution from its original state, and the current environment should be reflected in the new environment. Remember that the current environment includes the way in which people use the applications, as well as the technology and platforms on which they run. Thus the conceptual design must capture any changes from the original conceptual design that exist in the current environment. It is important to articulate that design in the functional specification for the migration project because it serves as a starting point for subsequent design activities.

Another possibility is to consider expanding the current environment's design. Guidance for these improvements is beyond the scope of this document.

The conceptual design should include the following:

A description of the problem to be solved
A description of the user and business needs and a list of features or functions that must be provided by the final state of the solution
A description of the future state, after the solution is delivered

You should review the conceptual design against the business and user requirements established during the Envisioning Phase.

Problem Description

If you are considering a Sybase database migration, it is likely that your organization has determined a need to define a solution that addresses increasing costs, increasing performance requirements, technology modernization, or any combination of these needs. The current database environment may deliver on the current business requirements, but a possible reason for the migration is that delivering more capacity or additional features is not a viable or desirable option. The conceptual design will specify which of these needs the solution is expected to address and describe the state of the database environment after migration. See also the problem description section of the vision/scope document. The vision/scope version of the problem statement is generally at a higher level than the conceptual design.

User and Business Needs

The solution must promote and support users' needs as well as the business requirements that define them. Embracing user needs in a migration often requires little or no changes from the current environment to properly support those users. Planning for solutions that bring about functional differences from the current environment should be avoided for initial migration efforts. Extending the functionality of the current environment should be viewed as a post-migration project.

A vital part of any acceptance test plan should be that the new system behaves in the same way as the old system. Changing the functionality will make this test harder to prove, and greatly increases the risk of subsequent failure.

However, occasionally there may be some external business drivers, such as regulatory compliance, which have driven the migration in the first place and which require functional change. You should make every effort to add new functionality in a post-migration step, and consider combining migration and functional upgrades only if there is no possible alternative. A cost-benefit analysis should be added to the risk-assessment in such cases.

Future State of the Database Environment

Some desirable features of the migration are:

Realization of business requirements. The migration should actually provide the cost savings, performance increase, or modernization that represent the impetus for the project and that the business sought.
Congruence between the current database environment and migrated database environment. No (unexpected) changes in the user experience should be found in a post-migration environment.
A supportable technology solution. The (support) organization should be capable of supporting the post-migration environment.
An extensible technology solution. The post-migration environment should provide all of the desirable opportunities to extend the migrated environment as needed.

Logical Design

Logical design is the process of describing how all the parts of the solution work together. It therefore defines these elements, shows how they are organized as part of a structure, and explains the interactions between the elements. Logical design takes into account all of the business, user, system, and operations requirements. These include the need for security, auditing, logging, scalability, state management, error handling, licensing, globalization, application architecture, and system integration. It is strongly recommended that you create a diagram or model that represents the output of the logical design process. The diagram should identify all of the logical objects and account for all of the essential functionality of the solution. This will help the team both to understand the design and to identify missing links, inconsistencies, and redundancies.

The logical design begins with and is based on the conceptual design, which identifies the business needs that the solution must support. It should include the following considerations:

Identify appropriate technologies for use in creating the solution.
Identify technological constraints of the components, if they affect requirements.
Define the parts or components selected to accomplish the solution.
Define what the selected parts or components do in the solution.
Frame the associations of the components used in the solution.
Validate the design against the user and business requirements.

Logical design takes each piece of conceptual design and assigns it to a specific logical role within an architecture. The architecture might be a series of block diagrams showing networks, service components, and network connection elements. Application architecture is typically broken down into at least three levels: presentation, business, and data.

Because this is a migration project, the team should document the existing logical design as well as the logical design of the migrated application, emphasizing the areas of change. It may be necessary to show how other components outside the scope of the project interact with the subject of the migration.

Identify Appropriate Technologies

A migration project may contain a myriad of requirements spanning many subject areas. In this case, it is likely that several people will be involved in identifying tools that may contribute to the solution. As the methods or technologies are identified, they must be documented, investigated, and possibly tested for their usefulness or applicability in the solution.

Identify Technological Constraints

As technologies or methods are considered, some of them may provide all of the required features, while others may provide only some of those features. In some cases, there may be constraints that arise only under certain conditions. All of these constraints,

shortcomings, or issues must be identified to ascertain their impact. It may turn out that the constraints are either not an issue or may eliminate the component's viability in the solution. All of these details should be used in the selection of suitable components for inclusion in the logical design.

Select the Components

Through the process of consideration and elimination, you will select a list of architectural components. This list will later help you to create the solution's physical design. The components selected at this point are not line item specifications; they are general statements describing (not specifying) the components, as in the following example: two servers, high bandwidth/low latency network, and Storage Area Network (SAN).

Frame the Associations of the Selected Components

The various components selected for use in the solution may not make complete sense to anyone who is not intimately familiar with them. Create a description of the components and their relationships. While this may not be seen as necessary by some of the team members involved with the migration, there will be advantages to having a clearly stated description for people who are not familiar with all of the activities involved in database migration. This is particularly important if the team is geographically distant, has a mix of cultures, or includes external resources.

Validate Logical Design against the Requirements

You should now have a solution that can be validated against the business and user requirements that are driving the migration. At this point, if the solution components do not deliver the expectations derived from requirements, it is time to resolve those issues. This may require invoking for the first time the change control procedures the team has instituted. After those issues are resolved, the validation should have been successful and the next step, physical design, can commence.

Physical Design

Physical design is the process of describing the components, services, and technologies of the solution from the perspective of development requirements. The physical design defines the parts of the solution that will be developed, how they will be developed, and how they interact with each other.

The physical design of the solution specifies which logical pieces fit into specific physical pieces of architecture. The physical design should include anticipated metrics to assess the performance goals, uptime goals, and milestones of the solution code to be written. For example, the physical design might include metrics for transaction speed performance requirements before deployment.

Physical design should include the following activities:

Identify the scope of the physical design.
Specify the physical design's components.
Identify the implementation details.
Build the physical design specification.
Diagram the physical design.
Validate the design against the requirements.

These activities are discussed under the following headings.

Identify Scope of the Physical Design

Identify the critical hardware components of the physical infrastructure and articulate how they may or may not interact with the existing infrastructure. For example, can some servers be redeployed for this migration project? Is there sufficient capacity and bandwidth available in existing disk farms?

Any scope statement defines the boundaries of a particular piece of the project plan, describing what may be allowed in the scope, and what is forbidden by it.

Specification of the Physical Design's Components

This involves the selection of the appropriate solution from the technologies identified in the logical design for implementation in the physical design. This activity defines the key components that the solution will be based upon.

Identify Implementation Details

These details may include the use of a particular component or tool, or prescription of manual methods that must be employed to perform all or part of any required action.

Building the Physical Design's Specification

As the component technologies and implementation details are specified, the physical design's specifications can be prescribed. The details of the solution, resolution of issues, and component selection allow the physical design specification to be created.

Diagram the Physical Design

Create a diagram of the components and their relationships. While this may not be seen as necessary by some of the team members involved with the migration, there will be advantages to having a clearly drawn solution diagram for people who are not familiar with all of the components involved in database migration. The Physical Design diagram is usually the clearest way of describing the interrelationships among the components.

Validate Against the Requirements

The solution design should represent a migration solution that can be validated against the requirements that are driving the migration. A successful solution design meets the needs of the customer and key stakeholders.

Proceeding to the Work of Designing

Chapters 4 and 5 discuss the issues that are involved in planning for the migration of the Sybase databases and associated client applications, respectively. Guidance is provided to help you apply the assessment and solution design concepts discussed in this chapter to develop a solution design and functional specification for both parts of the migration.

Download

Get the Solution Guide for Sybase/UNIX to SQL Server 2000: Database Engine Migration and Application Interoperation Guide

Update Notifications

Feedback

Send us your comments or suggestions