Chapter 2 — Envisioning Phase
Published: June 21, 2004 | Updated: October 29, 2004
On This Page
Introduction and Goals
Deliverables of the Envisioning Phase
Creating the Team
Defining the Project Structure
Defining the Business Goals
Creating the Vision and Defining the Solution Concept
Closing the Envisioning Phase
Introduction and Goals
This chapter provides the background and technical information required to complete the first phase of a Sybase database migration project. It describes some specific deliverables that the project team creates and activities that it undertakes.
However large or small an organization is, a successful migration project will follow the five phases described in this guide. Smaller organizations with simpler projects may choose a more informal implementation, but should nonetheless recognize and adhere to the distinct purpose of each phase to help ensure the success of the project. The size and complexity of the project are determined in the Envisioning Phase.
The primary goal of the Envisioning Phase, which represents an early form of planning, is to create a high-level view of the project's goals and constraints and for the business and IT to agree on them. Although IT projects can originate from either the IT organization or the business it serves, the impetus for a migration project will most often come from the business. Agreeing upon a vision statement begins with defining the business opportunity or problem that the solution is expected to address. The vision describes the desired future state of the application. It may be crafted by the project team or handed down by the business and negotiated as needed, and it is documented in a vision/scope document.
There are many reasons that an organization may contemplate a migration, including:
Mergers and acquisitions, where two previously separate organizations with differing technology are now a single entity and want to merge their data (a business decision)
Licensing simplification, where the business has negotiated a substantial reduction in licensing costs by moving to a different platform (a business decision)
The need to integrate with other applications that require a different database platform (a business/technical decision)
Improved features/functions (a technical decision)
Reduced TCO through homogeneity (a business decision)
The Envisioning phase starts with the appointment of a Program Manager (PM) to manage the entire project and to organize a core project team. As members come on board, they join the PM in articulating the vision and then working to understand the problem in more detail. This is done by defining business and user requirements, determined by the various roles, either within the organization or externally, that will use the technology.
This detailed information enables the team to build a solution concept, which describes at a high level how the solution will solve the business problem in terms of the approaches it will take to build and deliver the solution. It documents business and design goals, expected functionality, assumptions, and constraints. It also defines the success criteria for the project, which helps the team establish the scope — the parts of the vision that will be accomplished in the current effort. Defining the success and acceptance criteria at this early stage is essential for the project, and never more so than if the work is to be undertaken by an external organization. Both the solution concept and the scope are incorporated into the vision/scope document.
Finally, the team makes an initial risk assessment in which it seeks to identify and qualify the various risks that the project faces. The first phase of the project ends with a milestone, Vision/Scope Approved. To meet the milestone, the business sponsor, (sometimes known as the “customer”) the major stakeholders, and the project team members must accept the vision/scope document (usually in a formal meeting) as a statement of the proposed solution and how it will address the business problems. Meeting the milestone also signifies that a project team has been established, the scope is clearly understood by the business sponsor, major stakeholders, and the project team, and the risks have been assessed. At the end of Envisioning, the business and IT department should have a clear idea of the goals for the project and the project team can begin to make specific plans for how to achieve them.
Many organizations want to see some sort of “proof of concept” or prototype very early in the overall project to determine if they will follow through with the entire migration. Within the Microsoft Solutions Framework, such a step typically occurs during the Planning Phase, and is discussed in this guide in Chapter 5. Producing a prototype earlier than this risks proving the wrong concept, or building a prototype that does not meet any of the requirements. However, the development team may use some prototyping to provide input to the Envisioning Phase.
Deliverables of the Envisioning Phase
Three documents comprise the key deliverables that you must have in place to meet the Envisioning Phase major milestone that ends the phase. You may have other documentation, such as use cases, underway during this phase, but the documents in the following list (which are explained in detail later in the chapter) contain the key information that needs to be understood and agreed upon to move into the next phase.
Project structure document. This document defines the approach the team will take in organizing and managing the project.
Vision/scope document. This document describes the goals, constraints, features and acceptance/success criteria of the migration solution and defines an initial schedule for the project.
Risk assessment document. This document describes the initial risks that are associated with the project and the contingency plans that are designed to mitigate significant risks.
Creating the Team
Building the core project team is the first undertaking in the Envisioning Phase. See the "Setting Up a Team" section of the UNIX Migration Project Guide (UMPG)* *for guidance on creating the core project team of six roles:
In some cases, parts of the project may be “outsourced” to external organizations. In such cases, it is important to consider the project team as a whole, even if some roles are undertaken by one organization, and the remaining roles by another. It is even more important in such circumstances to understand where and how the different roles interact, and to ensure that communications work well across the organizational boundaries.
Each role is built around a fundamental goal that the project must achieve to be considered successful. The UMPG also discusses the following team-related topics: building performance project teams, scaling teams according to the size and complexity of the project, the risks of combining roles that are intended to check and balance one another, and the changing importance of different roles throughout the phases of the project. The UMPG is available at http://www.microsoft.com/technet/interopmigration/sag/unix/umpg/default.mspx.
Though much of the work of Envisioning may be done by the Program and Product Management roles, which are normally the earliest team assignments, all 6 roles should be filled before the phase ends.
Assigning Roles and Responsibilities
Although it is premature to name all members to the team, individuals should be named to the core team roles before the end of the Envisioning Phase. For roles such as Development that will require multiple individuals to fulfill them, the core team member will become the lead and be responsible for working with Program Management to bring on other individuals in the Development Role as they are needed.
Successful Sybase on UNIX to SQL Server on Microsoft Windows® migration teams generally include subject matter experts to fulfill the functional responsibilities and provide the skill sets described in the following "Core Team Roles" section. In addition, members of the core team will work with individuals who are responsible for specific aspects of the technology infrastructure, such as system security. The "Extended Project Team" section, which follows "Core Team Roles," identifies other groups within the organization who will contribute to the project.
Core Team Roles
The following table identifies the knowledge and skill requirements for each role. It also lists the responsibilities and tasks of that role in the project. Use Table 2.1 to build the project team. For roles such as Development, where several persons and even entire subteams will likely be required to fulfill the role's responsibilities, the persons assigned to the role should collectively meet the knowledge and skill requirements.
Table 2.1: Knowledge and Skill Requirements for Each Team Role
Knowledge and skill requirements
Project responsibilities and tasks
Product Management Role
– Understanding of the organization's business priorities and goals
– Management and communications skills
– Ensure that the team addresses business goals and customer requirements
– Manage communications, launch planning, and feedback with customers (both internal and external)
Program Management Role
– Project management skills
– Communication skills
– Adequate knowledge of UNIX and Windows environments and of Sybase and SQL Server databases to drive solution design
– Drive solution design
– Manage project to meet budget and schedule
– Manage scope and track progress
– Provide process leadership
It is recommended that two subteams be created for the Development Role. One development team should focus on migrating the database. The second development team should focus on migrating the client.
Development Functional Team #1 (Database)
– Knowledge of security configuration for current Sybase database and applications running on UNIX
– Knowledge of shell and other scripts used to support the Sybase database
– Knowledge of times and orders in which scripts are invoked
– Understanding of security, connectivity, and software and database installation issues in the Windows environment
– Understanding of both UNIX and Windows environments
– Understanding of DB-Library/CT-Library/ODBC APIs
– Understanding of the Sybase database schema, including segments, tables, views, internal and external stored procedures, triggers
– Design an appropriate security model for migrated databases, based on analysis of application and database questionnaire responses
– Implement the security model in the database server
– Identify and resolve issues associated with Windows security and connectivity
– Validate that the chosen security configuration provides at least the same security level as the existing configuration
– Apply appropriate permissions at the database object level
– Ensure that requirements of Windows environment are met for migrated database
– Identify and provide access to shell and other scripts that are used to support the database being migrated
– Migrate user accounts and verify that they have been migrated correctly
– Install software and database applications on servers
– Identify the time and order in which the shell scripts are invoked
– Work with test groups to build test environment
– Work with client development functional team on issues related to connectivity
Development Functional Team #2 (Client)
– Knowledge of Sybase client applications and their security requirements
– Understanding of rights management issues associated with applications
– Proficiency in either C or Microsoft Visual C++
– Experience with Sybase DB-Library API, CT-Library API, ODBC driver and possibly FreeTDS and unixODBC
– Understanding of stored procedures, database logic, and application logic
– Understanding of connectivity issues with database
– Participate in assessment activities for client applications
– Identify and articulate security requirements for client applications
– Retarget existing client applications
– Migrate existing client applications
– Work with test team to ensure requirements are met and defects are reduced
– Work with database development functional team on issues related to connectivity
User Experience Role Cluster
– Understanding of applications being migrated
– Experience in developing usage scenarios and use cases
– Understanding of training principles
– Manage process of gathering, analyzing, and prioritizing user requirements
– Develop usage scenarios and use cases
– Provide feedback on solution design
– Drive the creation of user training materials
Test Role Cluster
– Understanding of the UNIX and Windows operating systems (including SFU, if appropriate)
– Expertise with Sybase databases, application and client development
– Experience with FreeTDS or unixODBC (if used in the migration), and scripting
– Understanding of tiered database systems in homogeneous and heterogeneous environments
– Participate in data gathering relevant to Test during all phases of the project
– Design and develop the test environment in conjunction with the Development functional teams for database and client migrations
– Maintain ownership of the test environment
– Design, create the specification for, and refine the test plan and the user acceptance test plan
– Implement and validate the migration test plan
– Implement test cases
Release Management Role Cluster
– Understanding of standard operational procedures in Windows environment
– Understanding of applications being migrated
– Management and communication skills
– Act as primary advocate between project development and operations groups
– Manage tool selection for release activities and drive optimizing automation
– Set operational criteria for release to production
– Participate in design, focusing on manageability, supportability, and deployability
– Drive training for operations
– Drive and set up support for pilot deployments
– Plan and manage solution deployment into production
– Ensure that stabilization measurements meet acceptance criteria
Project Resources Mapped to Organizational Titles
For some team roles, such as Development, a variety of skill sets and knowledge are required. In this case, the best resources for the role may currently hold a variety of job titles within the organization. The following list maps team roles to organizational titles or functions that often fill them.
Product Management Role
Program Management Role
Sybase Database Administrator
SQL Database Administrator
UNIX System Administrator
Windows System Administrator
UNIX Application Developers
Windows Application Developers
Windows Infrastructure resource
User Experience Role
- Business Analyst
Test Engineering Manager
UNIX Database and Applications Testers
Windows Database and Applications Testers
Release Management Role
The Extended Project Team
To accomplish the migration, the core team will need to work with several individuals in your organization who can be thought of as the extended project team. These individuals typically hold organizational positions within the following areas, which may be aligned in different ways in your particular organization:
IT senior management. This group will include the high-level technical decision-makers for the project and is likely to work with the Product Management role in interpreting business goals and ensuring that they are met. It ensures that the team has the complete cooperation of the current "owners" of the existing system. It may work with the team to provide advice on the network infrastructure and security requirements.
Infrastructure administration. This group will be responsible for managing and maintaining the new architecture. Infrastructure administration handles the day-to-day running and organization of the platforms that the databases and applications will use.
Network administration. This group "owns" the network (wiring, routers, and other network infrastructure) and is responsible for network provisioning, controlling hosts, and computer access. This group will be responsible for providing development and test network environments within the corporate network.
Security administration. This function is responsible for recommending a security model and solving security issues of the migrated system. The security function is most involved during the planning and post-deployment phases, but is responsible throughout the project for ensuring that a focus on security is maintained.
Development. Your organization may have a group that owns the software development arena or portions of the different software development arenas that will need to be consulted when the migration begins. Defining your plans and needs to this important group will certainly be in the best interest of the entire project. If the development work of the migration project is to be “outsourced,” it is critical that any existing internal development team is as closely engaged with the external team as possible.
Technical support. Your organization's technical support group may be either internal or external, or a combination of the two. You should include support personnel early in the planning stages of the migration. This group will be responsible for the support of the migrated application, and their requirements must be included in any requirements analysis.
Assessment of Team Readiness
As you identify individuals who have the knowledge and skills that are required for team roles, you may also identify some gaps. The currently existing resources within your organization may not meet all of the project needs. You will need to perform a gap analysis to determine all of the skills and knowledge that will be required and all that is currently in place. For information about the complexities of the migration that will help you scope the particular skills and resources your migration will require, see Chapter 4, "Planning Phase: Database," Chapter 5, "Planning Phase: Clients," and Chapter 6, "Planning Phase: Building the Development and Test Environments," of this guide.
You can fill the gaps in two ways. The first is by providing training to supplement the knowledge and skill sets of team members that you choose from your organization. These team members will bring certain knowledge and skill sets to the project by virtue of their current organizational roles; however, they may need additional knowledge and skills to fulfill the expanded roles that they assume during the migration. Some of their training needs are introduced by the new technologies and tools, whereas others may be the result of project responsibilities. For example, some team members may require project management skills that their previous roles in the organization did not entail.
The second way to fill gaps is to acquire resources externally. Depending on the type, scope, and critical importance of your project, you might choose the flexibility of securing highly-skilled resources from outside the organization to fulfill certain critical responsibilities, such as architect-level expertise. Such an approach would allow you to make immediate progress toward milestones while implementing a training plan to develop in-house capabilities for later aspects of the project.
When using external resources, whether it is one or two individual consultants or the outsourcing of an entire team, it is important to balance the specialized knowledge they bring against the fact that they do not know your organization’s internal business requirements. Seamless communications with external people or groups is even more important with than with insiders.
The early learning requirements for a Sybase migration project team include the following:
All team members must have access to this guide and should understand the Sybase migration issues discussed in chapters 1 though 5. A command of this information is critical when planning the various components of the solution.
At a minimum, the migration team lead should be familiar with the UNIX Migration Project Guide (UMPG), the process-oriented companion to this guide.
Development team members should be familiar with the details of the Sybase client application and should become familiar with the database and implementation differences between Sybase and SQL Server 2000. For more information, see Appendix B, "Architectural Differences."
Defining the Project Structure
Program Management initiates the definition of the project structure, documented in the Project Structure document. This document outlines the project organization and details how the team will manage and carry out their tasks to create the solution. The project structure document becomes an essential reference for team members on how they will work together to successfully complete the project.
The project structure defines team standards for communication and such processes as documentation, change control, and configuration management. It also generally defines roles and responsibilities of each member, including who is responsible for each milestone; how logistical issues are handled, such as meetings of a geographically-dispersed team; and reporting requirements that are related to schedules and milestones. Generally, the project structure reflects preexisting policies and methods that are in use in the environment and incorporates new methods that the migration project requires. A template is included in the job aids to help you create this document.
Project Structure Overview
The process flow illustrated in Figure 2.1 provides an overview of the project structure definition phase. The content of each process step is discussed in the text that follows.
Figure 2.1 Developing the project structure
Project Team Roles
The project structure document should specify the makeup of the team and the roles and responsibilities that each team member is designated to fulfill. If you decide to use separate functional teams for the development role in the database migration and the client migration, this document should reflect that decision.
Good communication is essential to planning, risk management, milestone achievement, and the overall success of the project, and even more so if there are any external resources involved. Communication standards define strategies for information sharing, especially as it pertains to documents that guide and control the project, such as plans and schedules, specifications, and so on. The standards also define: strategies for the publication of contact information; the type, purpose, and schedule of regular meetings; training schedules and participation; and requirements for any regular project-specific communications that the team requires.
Specific issues that the communication standards should address include:
Who is responsible for approving each type of decision that is required to carry out the project, such as specifications, test methods, development tools, and acceptance criteria?
Who will monitor and handle changes to solution specifications?
How will changes to risk factors be addressed (for example, training and staffing needs that are identified after development begins)?
How will problems that arise while implementing migration plans, including escalation procedures, be managed?
What are the approved methods for securing input to the assessment process (described later in this chapter) and for distributing the collected data to team members to use for project planning?
Who will be responsible for managing roadblocks that arise during development?
Who will develop a post-migration project retrospective that includes the perspective of all team members?
As you review requirements for project communications, consider the geographical locations of team members and groups that will support the migration effort. Also include a specific plan for alternative methods of communications to mitigate the possibility that reliance on electronic communications could adversely affect project timelines. Decide on specific methods for documenting different types of issues that arise and events that commonly occur during a project.
A common strategy is to develop a project Web site using a technology such as a Microsoft® SharePoint™ portal server, which is easily accessible to everyone supporting the project and can be customized to provide document storage, change control, and comment capabilities.
As you consider the requirements of your migration project, give thought to special communication strategies that are appropriate to particular phases of the project. For example, roundtable strategies can be effective for the triage of issues in the validation and test phases of a migration.
The project structure defines the types of documentation that you will use to store important information about the project and your current environment. Review the "job aids" listed in Chapter 1, "Introduction," for an overview of the types of information that you need to document and track during the project. You should ensure that a process is in place for managing and publishing this documentation, especially documents that guide development of the solution, such as the functional specification and test environment requirements.
You will need to inform team members how they can access important resources they will need for documentation, communications, project management, change control, and configuration management. This information should be captured in the project structure document.
Documentation standards should also include coding standards for the development team.
Every major project suffers from “scope creep” and other functional changes to the deliverables during their development. These changes will affect the completion date and the overall acceptability of the project, as well as its budget. Clearly understood change control procedures help to mitigate any negative impacts of such changes. While some changes can reduce the budget and make the project complete earlier than expected, in almost every case making changes ends up costing more money and time.
Change control standards and tools help to manage both project documents and components of the solution that are subject to revision or iteration. You must clearly define these requirements and processes in the project structure document.
It is also important to communicate to all involved people in the extended team that changes frequently arise from interpretation of requirements, where the originator and the implementer of a requirement have different interpretations of the written words. Change control can and will arise from such misinterpretations, so clarity in expressing such requirements is vital.
Configuration Management and Source Code Management
A major task in any Sybase migration is the transformation of database objects, such as stored procedures and dynamic Transact-SQL statements, which inherently change both the client and database source code. To maintain a known state as you work toward and eventually begin migrating your technology, you must address two aspects of configuration management in your planning:
Changes in the premigration environment that take place after the assessment process but before deployment of the solution. Change management in the area of configuration becomes critical if you encounter problems during the migration and you are forced to return production to the premigration environment.
Changes that occur during development and testing of the solution (that is, the new versions of source code).
During the testing stage, knowledge of and control over the test environment configuration is critical to understanding the results that you receive. If you are able to see exactly which aspects have and have not changed, you will be able define how the results of a given test are relevant to or different from future tests.
If your configuration management tool allows you to manage database objects and source code in the same way that you manage other components of your configuration, this feature will be an asset to your migration project.
The project structure should document your strategy for identifying and tracking the training needs of your team (the team readiness assessment discussed earlier) so that you are able to develop a complete set of training plans during the Planning Phase. One training plan will address the training that team members need to complete the project. A second plan should cover training needed to operate the new technology when the project has ended. In many cases, the same persons who participated on the project team will be the ones to assume some of the operating responsibilities, so they may need both types of training. The plans should be kept separate, however, to accommodate situations where implementation is staggered, and one group may need to operate a migrated database while another group continues to work on the migration of other databases.
Interim Milestone: Core Team Organized
At this point, you should have completed the following tasks:
Defined the project structure, including the project team roles, responsibilities, and high level training requirements.
Made key team member appointments.
Documented and received approval on the project structure.
Defining the Business Goals
Before the team can form a shared project vision, it must define the business goals that the migration hopes to achieve and determine what problems or opportunities the team must address in the migration solution. For example, a migration project might take advantage of expanded features and capabilities offered by the new technologies found on Microsoft platforms.
The following section provides information on the benefits of migration to SQL Server on Windows Server 2003 that you can use in discussions between team members and business sponsors as you define the business goals of your particular project. Note that each solution option may not deliver all of these specific opportunities to your particular organization. If an economic justification analysis is required to move your project forward, refer to the information in the Rapid Economic Justification case studies.
In conjunction with the information presented in this guide, you may also want to consult the SQL Server documentation site at http://www.microsoft.com/sql/techinfo/productdoc/2000/default.asp
Migration from Sybase to Microsoft technology can achieve a lower total cost of ownership (TCO) in several areas:
Commodity hardware is less expensive.
Using Microsoft software often reduces current licensing costs.
Existing clients and applications can often support SQL Server.
Productivity return on investment may be improved because administrators are able to be more productive using the comprehensive set of tools available on the Windows platform.
Similarities between the Sybase Adaptive Server Environment (ASE) and SQL Server enable you to take advantage of the existing knowledge and skills of Sybase database administrators and developers in your organization.
As your enterprise expands, you have access to a larger pool of highly-skilled but less expensive human resources to support the new environment.
It may be possible to consolidate existing databases onto a smaller number of servers, reducing hardware and administration costs.
Taking Advantage of the Existing Investment
You might want to take advantage of existing clients and applications, perhaps by remaining on the existing platforms. There are distinct advantages in adopting this approach if at all possible:
Common development strategies employed with Sybase and SQL Server minimize application reengineering and the need to retrain database administrators and developers.
By taking advantage of your existing applications, you minimize the risk of business interruptions during migration. Many DB-Library and CT-Library applications can be redirected to SQL Server, either using the Sybase client libraries or FreeTDS, depending on the target platform and the version of TDS being used.
Support for Rapid Development
SQL Server has many advantages that aid rapid development:
It is relatively easy to install and manage.
Developers can use familiar Microsoft tools to build applications on it. Furthermore, a cadre of experienced Microsoft Certified Partners is available to help with building these applications.
It provides a comprehensive set of features that enable you to improve the capabilities of your environment.
Windows Environment Advantages
The extensive deployment of the Microsoft platform provides access to the widest array of experts, training, and third-party applications, minimizing cost and risk while maximizing flexibility and opportunity for evolution. In addition, Microsoft technologies represent a solid platform with long-term prospects for the future.
Creating the Vision and Defining the Solution Concept
You should now be ready to formulate the vision/scope statement, a concise statement that is used to establish a common vision for the solution and provide a context for making decisions throughout the project, given its defined constraints. This statement should help both to refine your thinking at this time and later, and promote understanding and acceptance of the solution design after the team creates it during the Planning Phase. It is subject to approval by the project team, customer, and key stakeholders before the Planning Phase of the project can begin.
Defining High Level Requirements
A high-level requirement is a condition that the solution must meet, and will help the team articulate both the problem statement and the vision. Defining high level requirements focuses first on business requirements. Although the technological details of the project will soon absorb the team's attention, it is important for them to remember that the solution must be business-driven. Business requirements include the needs of the sponsor, key stakeholders, and end users. Typical business requirements include the need to:
Replace outmoded software that is no longer supported by the original vendors.
Update or replace hardware that is obsolete or is no longer capable of supporting the business workload.
Reduce operational costs by providing an environment that provides a lower TCO.
Standardize on an operating system and database management system sourced from a single vendor, to remove any compatibility issues.
Identifying Stakeholder Requirements
A key task for the preliminary project team is to identify every group that will be affected by the processes or outcomes of implementing the new technology. These groups are, or become, the project stakeholders. Their requirements also need to be considered in defining the problem and conceiving a solution.
Capturing a record of the contributions that each group makes to the current work and accurately defining the outcomes that they expect will help to ensure that no important requirements are overlooked in the solution. Include every function that has a role in the project, whether the function's involvement ends with rollout of the solution or begins after the solution is in place. You can often capture this information by documenting scenarios of the tasks that each group performs, the problems that they encounter, and the impact of those problems on outcomes. You can then use it to develop user profiles, which will become part of the vision/scope document.
Stakeholders determine whether each phase of the project has adequately addressed the stakeholder expectations. The approval of key stakeholders is required at every milestone of the project before the next phase can begin. Always obtain acceptance criteria for each and every requirement as stakeholders identify them. This will help reduce future change control and lead to speedy approval at milestones.
Creating the Vision/Scope Document
Use the vision/scope document template job aid and the instructions included with it to create your document. Keep in mind that this guiding statement for the project should be a working, dynamic document that you modify as new information becomes available. However, after it has been baselined, it should be subject to the change control standards you have established in your project structure. This template job aid is available in the Job Aids folder in the download version of this guide.
The vision/scope document records the project team's shared understanding of the goals and constraints of the migration solution, as well as a shared vision of the future state of the organization's technology environment following the migration.
The items in the following list are entered into the vision/scope document based on states or viewpoints that are available during the Envisioning Phase. The vision/scope document may need to reflect changes or updates that are encountered as a result of information gathered during the Planning Phase.
The sections of this document include:
Problem statement. This statement is a brief narrative summary of the business situation going into the project and it defines the problem that the project will solve. While the statement is brief, it should be specific. Remember that the problem description determines the design of the solution.
Project vision. This statement is a brief description of the ideal state of the enterprise when the problem is solved. It should be specific, measurable, achievable, relevant to the problem, and time-based.
User profiles. The information in this section describes the goals and constraints of the people who will use the solution. It should include issues such as the functions and tasks that they perform, whether the hardware and software that they use is similar or different (and why), geographical issues (physical and cultural), information flow among users, and resources available to them.
Key assumptions. This section documents key assumptions to ensure that the necessary parties are aware of potential dependencies. These assumptions will also play a key part in future change control decisions should they be proved wrong in any respect.
Project scope. This section brings together the project vision and constraints (features that will not be compromised, such as security). It states specifically which aspects of the possible solution features are within the scope of the project and which are out of scope (that is, will not be addressed). You can begin by prioritizing the business goals and determining which ones can be addressed in the current project. A list of the major deliverables is also part of the project scope. Remember that project variables may not become clear this early in the project. Revision of the scope statement may be necessary to add clarity as you move into the Planning Phase. Scope considerations for the Sybase migration project that this guide addresses are discussed in more detail in the following section. You may have additional considerations for your particular project.
Project roadmap. This section defines the major project phases and what will be done in each phase. The remaining phases include Planning, Developing, Testing or Stabilizing, and Deploying. Issues that you should consider at this point include whether to do a proof of concept in early development and a pilot during the Stabilizing Phase (and to what extent the project will need to address post-deployment operations).
Risks. You can complete this section after you have performed the risk assessment, which is described later in this chapter. This section states the major identified risks to project success as recorded in the risk assessment matrix. You may incorporate the risk exposure statement into this section.
Solution concept. This section describes at a high level how the solution will solve the business problem and the approach that the team will take to build and deliver the solution. It also includes project success factors and acceptance criteria.
Developing the Solution Concept
The solution concept for a Sybase migration project will be a brief statement about how migrating the Sybase databases and reconfiguring the applications that are associated with this database meets business goals and requirements.
Two scenarios are possible when deciding which database or databases you will migrate:
Migrating all databases. If the business goal of the organization is to move away from Sybase entirely, then this will be the only option.
Migrating selected databases. If a wholesale move away from Sybase is not feasible for technical, risk, or business reasons, then you will need to determine which databases should be migrated to meet the business goals. This decision will be affected by any interdependencies that exist between databases, and the client applications that use them.
As described in Chapter 1, "Introduction," several options for reconfiguring client applications exist:
Retargeting the client. Client applications remain in their existing environment and are redirected to SQL Server.
Re-hosting the client. Client applications previously executing under UNIX can be copied to the Windows computer, hosted in the Microsoft® Windows® Services for UNIX (SFU) environment, and then redirected to SQL Server.
Rewriting the applications. Client applications can be fully ported to the Microsoft Windows platform and rewritten to take advantage of Microsoft technologies.
This guide concentrates on the first two scenarios. Because the project involves complex technical interdependencies, it will almost certainly not be possible to select a specific approach this early in the project.
The solution concept includes the solution acceptance criteria, which is a checklist that is derived from requirements that must be satisfied before the solution moves to production. The solution concept also includes the initial list of solution design goals and describes approaches for developing and delivering each aspect of the solution.
Interim Milestone: Vision/Scope Document Baselined
The vision/scope document as it now stands establishes the baseline vision of the project. This document becomes an important standard against which adjustments to various aspects of the project are measured as you move through the remaining phases.
Risks are inherent in any project, and migration projects are no exception. See the UMPG for a list of typical risks in migration projects and a discussion of the Risk Management Discipline that presents a five-step process for assessing and managing risks in IT projects.
Performing an initial risk assessment is one of the last Envisioning Phase activities undertaken by the team because the risks depend on the project vision/scope that has been agreed upon. Also, the core team will have been assembled by this time and each role will bring a different perspective to the process, which helps to ensure that possible risks are not overlooked. Risk assessment begins by identifying issues that can significantly affect the progress of the project or implementation of the specific solution.
The following lists of questions, organized by database migration risks and client migration risks, suggest some areas to explore to identify the risks for your Sybase migration. These supplement the list in the UMPG, they do not replace that list. The risks you identify will be brought to the attention of key stakeholder groups within the organization at the Vision/Scope Approved Milestone meeting. This helps to ensure that everyone involved with the project understands the importance of risk management to the overall success of the project.
Note Risk assessment is an ongoing process during the life of the project and should be participated in by all team members. The comprehensive initial risk assessment done at this time forms the baseline for project risks and requires frequent reevaluation during the project life cycle.
Risks Associated with Migrating Databases
Consider the following questions to help identify possible risks for your database migration. Many of these items require more detailed knowledge than may be available during the Envisioning Phase. Therefore, you should revisit this list during the Planning Phase when planning the database migration.
General Technical Risks
Is the manner in which your systems and networks are administered going to present any difficulties?
Do you have adequate technical support or in-house experience to perform the migration?
What are the performance implications of the change in platform? Is performance likely to degrade because of the use of hints, indexing differences or locking strategies between Sybase and SQL Server? Will application and client development strategies, or bugs in the platform affect performance?
What are the security implications?
What contingency and database disaster recovery plans are in place, and how will the new database support them?
Will you need to have interoperability with UNIX platforms that support clients and applications? (Interoperability with UNIX applications and scripts is enabled through SFU and FreeTDS.)
What impact would a delay in migrating a database has on any other dependent databases and applications?
Are you able to allocate enough time and resources to map dependencies accurately so that schedules for migrating and integration testing can be well-coordinated?
Are there any known bugs or issues with the existing system that need to be addressed during the migration?
Is the database of sufficient quality to be ported? Is supporting documentation available?
Is the source code for stored procedures, triggers, and other database items readily available? Are any of the stored procedures external?
How much data is there in the database? Is the data "clean?" Are there any data integrity concerns?
Are there any configuration and other management scripts that will also require migrating to support the operation of the database?
How will migration of the database affect the performance and connectivity of applications that use it?
Are there any changes in functionality that need to be implemented as part of the migration?
Does the database need to operate with other nonmigrated Sybase databases? Is the complexity of any dependencies between multiple databases a cause for concern?
What tools are available to help you perform the migration?
Are you migrating Sybase Open Server services, which need to be rewritten using analogous Microsoft technologies?
Does the original Sybase database employ technologies that are not directly addressable by SQL Server?
Risks Associated with Migrating Clients
The risks of migrating applications from one platform to another will be compounded by adding the complication of modifying the data sources used by migrated applications. The UNIX Application Migration Guide provides a detailed discussion of risk management when relocating applications from UNIX to Windows. The following lists summarize some of the more pertinent questions, similar to those suggested to help discover risks associated with migrating databases. This list of risks should be revisited when planning client application migrations.
General Technical Risks
Are your systems and networks administered in a manner that would present any difficulties?
Do people with the required experience to perform the migration exist in-house, or are they available outside the organization?
Do you have adequate technical support from application vendors?
Are there any specific constraints on standards-conformance or security requirements? For example, is the application safety-critical?
Would a delay to the migration cause any problems? For example, will there be problems in terms of new technologies or versions of software being released?
What contingency and disaster recovery plans are in place, and how will the migration affect them?
Are there any known bugs or issues with the existing system that need to be addressed during the migration?
The application itself is a likely source of concern. You can identify potential risk areas by answering the following questions:
Are the existing application code and scripts of sufficient quality to be ported? (You should include configuration and installation scripts where these exist.) Are there any known bugs or issues with the existing system that need to be addressed during the migration?
How comprehensive is the existing development environment? For example, do you have source control over configuration, build, debugging, and bug tracking information and data?
Is current application performance considered sufficient by its users? How will the migration affect this?
Do the applications depend on functionality not currently available through FreeTDS, or do they employ complex, dynamic Transact-SQL?
If any of your applications are third-party applications, are third-party libraries are available on, or portable to, Windows?
Is the planned version of Windows too new for the UNIX application, or is the UNIX application incompatible with Windows?
Is the technical complexity of the planned solution a cause for concern?
Does the original application require backward compatibility?
Note Many Sybase applications require minimal effort to work with SQL Server, and the implementations of Transact-SQL are usually very compatible. For more information about exceptions, see Chapter 3, "Planning Phase: Database." Applications that use ODBC or JDBC will likely require substantially less rewriting than applications that use CT-Lib or DB-Lib. For more information about migrating clients and applications, see Chapter 4, "Planning Phase: Client," and Chapter 7, "Developing Phase: Client."
Using the Risk Assessment Template
The objective of the risk assessment process is to identify the most significant risks associated with the migration project and to plan for how to avoid (or at least mitigate) those risks.
The migration risk assessment tool job aid can help you to identify, evaluate, and prioritize the risks to the project. Instructions for using this job aid are included as part of the spreadsheet. The job aid is available in the Job Aids folder in the download version of this guide.
Closing the Envisioning Phase
As you conclude the Envisioning Phase, you should have a good understanding of the goals of a successful migration and the risks that may appear along the way. In the next phase, you will begin to transform these ideas into actionable items — elements of the plan to make migration possible and predictable. The actionable items ultimately become the plan for your organization, guiding you through each phase in the migration.
Key Milestone: Vision/Scope Approved
When the project structure, risk assessment, and vision/scope document are complete, the project lead presents these documents to the team and the business sponsors. The contents of these documents are validated against project requirements, business goals, and stakeholder requirements, and then any indicated revisions are made.
Sign-off from all key participants is a requirement for proceeding to the Planning Phase.