|< Day Day Up >|
With a successful project justification and approvals in place, you need to start building a vital infrastructure that will make the migration successful. This section details the tasks involved in planning a migration project. From a high level, building the infrastructure involves the following tasks :
While the earlier chapters of this book focused on the reasons behind migrations and general technical strategies to approach them, this section starts addressing the logistics involved with turning a migration plan into a reality. It takes you through a detailed implementation of the migration methodology, illustrating key points with a sample migration project plan. In addition, this section presents techniques for identifying and assembling the technical skills necessary to execute the project plan.
As with any complex project, scope must be tightly defined and zealously controlled throughout the project. Scope creep is the number one threat to any migration project. Be prepared for people to try to seize upon the project to change some detail of the solution (be it hardware, software, tools, processes, or management) for their own needs. These attempts must be resisted at all costs. Migrations are complex projects when they have a proper scope, and additional challenges can mean the difference between success and failure.
In addition, however, you must ensure that scope is not too tightly defined. Shortcuts and omissions that occur during the architect phase will be uncovered during the implement phase, often resulting in a need to adjust the scope of a project. This flexibility to adjust scope, but only when absolutely required, can be the difference between the overall success or failure of a migration effort. Inflexibly resisting scope creep can affect customer confidence and completion of a project on time, but to try to incomplete specifications is a costly and pointless exercise.
Ideally, any migration project's scope will be the provision of equivalent end- user service or business support by way of a different platform, application, or process. Deviations from a scope should be fully documented with appropriate risks, mitigation procedures, and contingency plans as outlined in the following sections.
Understanding Risks and Planning Contingencies
Risks are inherent in any IT project. However, migrations tend to be considered the most risky because of the number of interdependencies they involve and the amount of change they produce. To minimize risk in migrations, you should follow a risk management technique. While many different techniques exist, most include the following components :
By choosing a risk management technique that has each of these components, you can actively monitor and control risk.
Because of the risky nature of migration projects, it is especially important to plan for contingencies in case your project runs into trouble. A contingency plan needs to be documented and approved during project planning so that it can be executed as an option should the need arise, not as a panic response that precipitates scores of other emergencies.
The following figure illustrates how risk is decreased with knowledge gained through an assessment of the migration opportunity. At one extreme, if you know absolutely nothing about the application and the associated infrastructure, your risk is high. On the other hand, if you have invested so much time and effort into understanding the environment and implementing proofs of concept that you have already completed the bulk of the project, your risk is nonexistent. The amount of effort expended during an assessment should be directly related to the level of risk the organization is willing to accept and the associated costs it is willing to pay, both in terms of labor and organizational disruption caused by the assessment activity itself.
Figure 4-2. Risk Evaluation Rating Graph
This section explains how to identify and estimate risk in a project and how to evaluate that risk. It then presents a common risk management technique and its application to migration projects.
All risks need to be stated so that they can be evaluated. There are generally two types of risk: business risk and project risk. Business risks prevent the project's ability to deliver the desired business benefits. Project risks jeopardize the project from delivering its objectives. In Chapter 1, we outlined a number of problems that can occur during a migration project. Any and all of these problems are potential business or project risks. They include the following:
The risks that you identify for your project should cover most of these, as well as any risks that are specific to your project, situation, or organization. It is not uncommon for complex migration projects to have dozens of risks.
Each identified risk must be assessed. This assessment measures the possible repercussions to the business or project from the identified risk. While there are many ways to perform this estimation, most methodologies use the sums of two numerical indexes to ascertain the total severity of a problem. Often, these numerical indexes relate to impact (the portion of the project the risk might affect), and severity (the level of detriment it might impose).
For example, the inability of your new tape drives to read legacy backup tapes would have a narrow impact (an impact level of one), whereas the inability to secure proper testing facilities would have a broad impact (impact level of five). Expressing the estimate as a numerical index between one and five, we might rate this situation as having an impact of four.
Each identified risk must also be categorized by the severity of its impediment to the success of the project. This too will be a numerical index representing a possible problem. In the example above, if the legacy tape drives were the only source of data and were quite rare, the inability to access them would rate as a high severity. However, because we can simply back up this data to another tape drive or across the network, we rate its severity as one.
After identifying risks and estimating their impact and severity, you need to evaluate and prioritize the risks to your project. This task allows you to concentrate on risks that pose the greatest threat to your project. Most methodologies prioritize risks according to the product of their numerical impact and severity ratings.
Continuing with our example above, we produce the risk evaluation rating of four by multiplying the impact score of four times the severity score of one. However, if we had to rely on these tape drives and the severity rating was four, our risk evaluation rating would soar to sixteen (4 x 4 = 16). These risk evaluation ratings become very clear when they are graphed.
Create Mitigation and Contingency Plans
Once all the risks have been identified and prioritized, mitigation and contingency plans must be created. Mitigation plans reduce the risk of the problem occurring; contingency plans outline the project's recourse if the problem occurs. Some of these plans should be built into the best practices of the project itself. For example, a common risk for migration projects will be the failure to successfully port the source code to the new platform. Mitigation steps for this risk include the following:
However, if these mitigation efforts do not lead to a successful port, contingency plans should be available. Contingency plans for this problem might include the following:
As you can see, contingency plans are formed at different levels, depending on the magnitude of the risk.
You should refine and update the risk and contingency methodology during each successive phase of the project. It is hoped that active monitoring will show a downward trend of these risks as the project goes forward.
Organizing the Project Team
The final piece of the migration project plan is the organization of people, their relationships, and reporting structures. While your specific project management framework will dictate many of the specifics of your general project structure, the following tips might help your migration project run smoothly.
The following figure shows a typical project organization.
Figure 4-3. Project Team
Each box within this illustration serves a specific purpose:
After detailing tasks and durations in a project plan, you should identify the resource profiles required to complete the tasks. Resource profiles are sets of skills that are required to accomplish groups of tasks within a project plan. For example, assessing the current platform and building the new platform are two separate tasks that require similar skills. To accomplish either task, you must have access to a person who understands the hardware and operating system technologies used in a particular environment. Once you identify all of the resource profiles for a particular project, you can assign people with these profiles to individual tasks, and begin creating a project plan.
The project manager and implementation team for the project should create the project plan. Although they will work closely with the engagement team to develop a plan and schedule that satisfies the business requirements and timelines , project planning is primarily a technical task and is best left to those who understand the time, skills, and efforts required.
Developing a Project Plan
Now that the project startup and initiation activities have been completed, it is time to construct a realistic project plan for your migration effort. While every migration project will be different in objectives, scope, difficulty, and level of effort, some standard steps and rules of thumb can be applied to any project plan.
This section focuses on the creation of a sample project plan, using the SunTone SM Architecture Methodology. Our sample migration will be a small, relatively simple migration that we are rehosting through a technology port of a custom C application that operates in conjunction with an Oracle database. The custom application is composed of about 4000 lines of code. For the sake of this example, imagine that the application was created to run in the HP-UX environment but the organization now wants to run it in the Solaris environment.
Architect a Migration Solution
Architecture is the first stage of the project that we need to tackle. In the SunTone Architecture Methodology, architecture is divided into three major areas: assessment, design, and prototyping. Each of these areas is aimed at advancing the solution toward a new design.
Assessment activities in this stage are straightforward. We need to investigate each layer of the E-stack within the solution and assess what likely changes are necessary to meet our goals of rehosting this on the Solaris OS. In terms of the project plan, we would create tasks for each layer of the E-stack, making sure that they document all the layer's important systemic requirements, possibly combining adjacent ones when necessary. We would combine layers only when we thought that a single resources could investigate that layer fully.
In our example project, we would construct a task list like the one shown in the following figure.
Figure 4-4. Example Task List
There is no set rule for the length of time needed for these assessment activities, but because this is a relatively simple migration with just two servers involved, we give each task one resource and one week to complete it. The output of each of these tasks will be a summary of the current situation, detailed information about key configuration items, and an estimation of the level of effort required to move to a new environment.
In our example project, we have divided the tasks between two roles: an application architect and a system administrator. The application architect investigates the upper levels of the E-stack, and the system administrator documents the current hardware platform.
With the due diligence of the assessment behind us, we can begin to concentrate on the two major tasks for the design of the new solution:
While each company will have different processes, methodologies, and standards for architectural design, the deliverable should be the same: an architectural report detailing the requirements and all components of the solution. The effort to create this deliverable will be much more variable than the preceding assessment because it fundamentally depends on the complexity of the current solution, not necessarily on its size.
For this example, we project three weeks to create the design. One week of that time is set aside for creating the requirements, and two weeks is set aside for the creation of the solution, as shown in the following example architecture schedule.
Figure 4-5. Architecture Schedule
The next activities in the architecture provide a proof of concept for the initial architecture. This is an optional step, depending on the level of risk and the project's mitigation plans. Many migration projects will include this stage, especially if they are migrating to COTS solutions. The prototype will usually take several weeks to develop and will result in the construction of a scaled-down version of the initial solution that can provide the functional validity of the solution.
In our sample project, we decide that a prototype is not necessary since the risks do not warrant the time or efforts. Because of the small scope of the project and our relative confidence in being able to port the code, it simply isn't feasible to spend the time and money necessary to complete this activity.
Implement the Migration Solution
With the architecture stage completed, it is time for implementation. In the SunTone Architecture Methodology, implementation is divided into many areas:
Each of these areas is crucial to successfully completing a migration.
Application Redevelopment and Porting Activities
In migration projects that rely on the porting or redevelopment of applications, this stage receives the most attention. Other migration projects, such as the migration from custom applications to COTS solutions, might not address it at all. These tasks include the process of developing, customizing, or porting applications so that they execute in the new environment. The key activities here include the following:
Again, these activities vary greatly depending on complexity. However, the key criterion in this level of effort is the application or porting complexity. Some applications will require very little porting assistance; for others, porting will be a massive undertaking. This doesn't directly relate to program size, but rather to the number and difficulty of changes required.
For this example project plan, based on the assessment stage data, we believe that the porting will take a significant amount of time. We budget two months for a team of two developers.
Data Conversion and Movement Activities
Similar to the developing and porting activities, this set of tasks readies the data for the next environment. However, in addition to the possible conversion of data from one format to another, there may be substantial challenges in actually moving the data from one platform and application to another. This is especially true of databases or any other application that handles data outside the normal UNIX file constructs.
For the purpose of our sample project, we budget only a small amount of time for data conversion and movement. As the data already resides in standard SQL format within the Oracle database, no conversion will be needed, just movement to the new platform. To be on the safe side, we allot two weeks for the planning, implementation, and testing of this movement.
The build activities of the implementation stage are similar to those of any other project. Infrastructure must be constructed so that the applications can be hosted. Some of the environments that will need to be built include the following:
In our sample project, this is a fairly simple task because the proposed solution is only one server. We allot three weeks to account for the amount of time that it takes to get onto the production floor.
One of the more important parts of a migration project is buried here in the middle of the project plan. Testing will make or break a migration project. Several types of tests need to be planned and executed:
We make sure to allow for ample time to test in our sample project. In fact, we give it four weeks, almost as much time as it took for development.
The final activities in the implementation stage address the overlooked human aspect of migration projects: training. Several levels of training will need to conducted to make sure that the newly migrated environment supports the business properly. The following types of training might be necessary:
Although this activity set is discussed last, it should actually be started before the build tasks within this stage so that administrators have good knowledge of the new environment.
Manage the Migrated Environment
The final stage of migration is making sure that the migrated solution will meet the previous service level agreements. We do this by addressing the operation and maintenance procedures with the same approach as for the human and technology issues in the project.
These are the key tasks in this phase:
Between each stage of the project, these key project evaluation documents need to be updated and reassessed:
|< Day Day Up >|