Assessing the Environment

Before undertaking any migration project, you must understand the environment that will be migrated . Regrettably, this is typically not an easy task. Organizational changes, attrition, and the inexorable passing of time often combine to make it difficult to understand the full scope of the application composition and the associated supporting infrastructure, as well as the various interconnects and dependencies that might exist. Ideally, the enterprise should be able to furnish a document set that contains all the relevant information that will be required, but this is rarely the case. Usually, the best you can hope for is that an individual or small group of people will know or have access to documentation that contains the relevant information.

It is critical that local sources, who are knowledgeable about the application, its component parts , its build environment, third-party products, interconnects, dependencies, and the like be assigned to the migration team. Without this guidance, the migration team might never completely understand the application and its supporting environment.

The goal of assessment is to ensure that all assumptions made during the project justification are proved and that all of the requirements and dependencies for the architecture are documented. This documentation is the deliverable for the project assessment of a migration project.

To provide complete documentation of the current environment, you must address the following major topics:

• Assessing technologies used in the existing environment, during which you perform the following tasks :

  • Assess the requirements of the application

  • Assess the requirements of the existing platform

• Assessing existing and new processes, which involves the following tasks:

  • Assess the new environment's ability to satisfy business requirements

  • Assess the development environment

  • Assess IT operations requirements and existing management capabilities

• Assessing skills and training requirements for the staff to support the migrated environment

When performing assessment tasks, you must be careful that you do not perform too cursory an assessment. Failing to uncover significant dependencies that could jeopardize the project's viability can easily lead to expensive architectural revisions. On the other hand, you must also be careful that you do not perform too detailed an assessment. Wasting time on minutiae that are not relevant to the migration can reduce project momentum and negatively affect the return on investment.

Assessing Technologies Used

When assessing the technologies used in an existing environment, focus on existing applications, the application infrastructure, and the platforms on which the applications run. The following sections describe how to assess each of these areas.

Assess Application Requirements

Before determining an appropriate migration strategy, you must determine the exact composition of the application that is to be migrated. Tasks you will usually perform during this part of assessment include the following:

• Interviewing application owners and maintainers

• Describing major software and hardware components used to support the application

• Identifying and documenting API differences between existing and new environments

• Identifying and documenting the effort required to transform source code

These tasks are detailed later in this book when specific case studies and the tasks involved in their development are described.

In addition to the common tasks you perform when assessing application requirements, consider the issues presented in the following sections with respect to the migration of a custom-written application or an off-the-shelf application.

Custom-Written Applications

For custom-written applications, examine the APIs used by the application that are specific to a particular OS. The fewer dependencies the application has on OS support, the easier it will be to migrate.

After you identify any dependencies that might exist between the application and the OS, develop an issues database that defines the API differences between the OS that currently supports the application and the new target OS. For example, you might find that differences exist in the parameters specified in the function call, the behavior of the function itself (what it does), or the format of the results that it returns. At this point, you can also create compatibility libraries that mimic the behavior of the original system, thereby minimizing the amount of change that has to be made to the application. These libraries usually do not contain solutions for all APIs provided by an OS, just those that are most frequently used. The issues database helps you assess the amount of effort that will be required to transform an application's source code to be compatible with the new OS. The compatibility libraries are used in the transformation process itself.

After you create an issues database, assign weights for each API provided by the source OS to indicate the amount of effort that will be required to change the logic or calling sequence within the application, following these guidelines:

• If the type or ordering of a parameter to the API has to be changed, assign the API a low weight because the change can be easily effected.

• If an existing compatibility library already supports that API, assign it a slightly higher rating to reflect that changes to the source code will include conditional compilation.

• If a solution for the API has yet to be created, assign it a high weighting to reflect that a substantial amount of work will have to be done implement a solution.

• In some cases, there is no way to replicate the functionality of an API because the target OS lacks the hardware to implement the required functionality. Assign these APIs the highest weight in the issues database.

Once the issues database exists, you can develop a tool that scans the source code of the application, looking up the weight of each API it finds. The sum of these weights determines a portability index for that particular application. You can then use the portability index to determine the level of effort (LOE) required to transform the code.

Note

To migrate code, you should understand how to perform the tasks described in this section. To access the issues database, compatibility libraries, and assessment tools when migrating to the Solaris OS, visit http://www.sun.com/migration/

Assessing application source code in this fashion provides a quick and objective measure of cost and effort that can be a useful input when you are determining a solution for a migration project.

Sun provides tools to assist your assessments of custom-written applications. The most important of these tools is called the Solaris OE Analyzer for C/C++ and Cobol Source Code. This Java technology-based tool, formerly called Score and then JScore, identifies porting issues with C/C++ or Cobol source codes from other operating systems. In addition to identifying these problems, it estimates their difficulty and suggests possible solutions.

The Solaris OE Analyzer for C/C++ and Cobol Source Code works by comparing the source code against databases of known porting issues. Using a modular approach like the methodology described above, the Solaris OE Analyzer for C/C++ and Cobol Source Code contains databases for the following operating systems:

• Microsoft Windows NT/9x

• Linux

• HP-UX 9.x, 10.x, 11.x

• AIX 3.x, 4.x

• SGI IRIX

• SunOS 4.x

• VMS

• Digital Unix (now called HP Tru64)

• HP MPE Cobol

Because this tool is in continual development, visit http://www.sun.com/migration/ntmigration/tools/jscoretool.html for the latest information on the operating systems it supports.

The Solaris OE Analyzer for C/C++ and Cobol Source Code is easily used. Simply execute either the JScore (Solaris) or JScore.bat (Windows) programs to invoke the GUI shown in the following figure.

Figure 6-1. Solaris OE Analyzer for C/C++ and Cobol Source Code GUI

Normally, you will need to adjust options on the Solaris OE Analyzer for C/C++ and Cobol Source Code. First, choose your platform's source code from the Platform Options pull-down menu. Then, click the Browse button next to the Please choose a single file or directory text box. Navigate to your source code top-level directory and click Select. While the tool has other options (all well described within the download help files and release notes), these two options are the only required ones. After the options have been chosen , click the Analyze button. The tools will then run your source code (or source code tree) through the selected platform database and present the migration analysis results, as shown in the following figure.

Figure 6-2. Migration Analysis Results

The migration analysis results are divided into the following three sections:

• Analysis summary. Details statistics of the source code files analyzed and the tool settings selected.

• APIs encountered . Lists the APIs found in your source code that are flagged as porting issues within the selected platform database. Each of these API issues is categorized by difficulty from Easy to Toughest.

• Detailed analysis. Cites specific source code files and line numbers at which each problem API was found. In addition to citing each call of these APIs, the report usually provides specific details about the solution to the problem. These details range from simple syntax solutions to complete reimplementation of the API.

With the results of this report, you should have a good idea of the specific areas that you will need to address in your porting effort, the general difficulty level of the port, and the possible level of effort required.

Off-the-Shelf Applications

In the case where a COTS product is to be migrated, a version of the product must exist for the new target OS. Although products are quite similar, regardless of the environments in which they are designed to operate , there will be differences in the ways they are implemented. COTS vendors usually provide guides that highlight the differences between versions of differing operating systems. Before choosing a migration strategy, examine the implementation to determine the amount of change required to move from one version of the product to another. The level of effort (LOE) for this activity is a critical input for choosing the migration strategy.

If a version of the COTS product does not exist for the new platform, the migration becomes a rearchitecture effort. Determining the LOE for this form of activity requires significant time and effort and is not as accurate as it is for code transformation.

Third-Party Products and Locally Developed Scripts

If third-party products are used to support the application, you must also consider the amount of effort required to migrate these products. The first step in this assessment is to determine whether a version of the third-party product exists for the target OS. If one exists, you will also have to determine API differences. Most independent software vendors attempt to keep consistent interfaces between different versions of their products. Differences should be minimal, but they must be evaluated. From this assessment, you should identify the LOE required to transform the code to use the third-party APIs, as discussed above.

If a version of the third-party product does not exist on the new platform, you will have to identify the functionality of the product and find a replacement for it. Differences between the APIs of different products will probably be significant, requiring changes in source code logic within the application. This effort is more like a reengineering effort than simple code transformation. Significantly more risk is involved in this effort because the appropriateness of the new product, as well as the amount of change that must be introduced to the application, might not be well known.

Databases are perhaps the most common form of third-party product used by applications. Some of the considerations involved in migrating databases are described in Chapter 11.

All third-party products must be assessed to determine their licensing costs and the services they provide. Changing third-party vendors might result in reduced licensing costs, but real savings might not be realized when the cost of integrating the new product into the application is taken into account.

Although they are not really third-party products, many applications are surrounded by a host of locally developed scripts that start, stop, or monitor an application. Scripts are also frequently used to age log files, collect and analyze data sets, and prepare input. All of these scripts must be identified in the application infrastructure assessment because they will have to be ported to the new OS.

Assess Platform Requirements

In addition to assessing applications, you need to assess the existing hardware ” usually the compute, storage, and network platforms ”to determine suitable replacements . These assets usually are examined in terms of capacity, scalability, price/performance ratio, maintainability, reliability, and availability. Hardware vendors usually provide this service without charge. Keep in mind that the platform assessment should provide an objective analysis of the existing system and its replacement. This analysis will allow for a meaningful comparison of the platforms when you are developing a migration strategy.

From the perspective of a migration, hardware design details must be noted. Differences between platforms might require changes or redesign to the application.

Big Endian Versus Little Endian

When assessing platform requirements, be sure to consider whether the application you are migrating was created in big endian or little endian format. If the standard APIs are used to access data, the endianness of the platform is usually not an issue, because the layout of the data in the word will be abstracted by the APIs used to access it.

If you are using lower-level languages or legacy coding techniques and an application uses operators such as shifts, or logical or arithmetic and s and or s, then assumptions about the layout of the word and, consequently, the significance of the bits, might become an issue. Application logic might have to be rewritten if it depends on the position of a bit in a word. In the past, when memory limitations were a concern, this was an issue.

Understanding the logic and replicating it using the different model can require significant effort.

Word Size

Most applications have been written to use a 32-bit data model. Although most 64-bit operating environments support 32-bit applications without modification, you might have to change the application if it interacts with an operating system kernel that uses a 64-bit data model.

Migrating an application to use a 64-bit data model rather than a 32-bit data model requires considerably more effort than the conventional migration between operating environments described above. That type of migration is primarily concerned with modifying APIs to be compatible with the new environment. An understanding of the program logic and the size of the data need not be considered. This is not the case when you are migrating to a new data model. The size of the quantities being manipulated must be considered , and what that manipulation is to accomplish must be understood .

In Chapter 11, we discuss data models and identify dependencies that will require data model conversion in more detail.

Proprietary Hardware Support

To obtain a competitive advantage, vendors sometimes develop proprietary hardware such as fault-tolerant CPUs or tunable crystal oscillators that minimize the skew in timers. Be sure to note use of such features during the platform assessment. Because software cannot simulate these features, their presence will require you to choose comparable hardware or to reengineer the business process.

In addition, the application itself might require the presence of special hardware to provide its functionality. This is frequently the case in engineering or process control applications. If the application controls a device that either provides a specific input or that can be used to effect a specific change, the availability of the device must be verified for the new hardware platform as well as for the device driver both of which will integrate into the operating system.

Assessing Processes Used

In addition to assessing the applications and platforms affected by a migration, you must also assess existing and new processes to ensure that the migrated application will integrate into the procedures executed by the enterprise.

Assess Business Requirements

The application provides functionality for specific business processes. Assess these processes to determine their requirements. When attempting to develop a strategy to migrate the application, always remember that the new environment must support all business-critical functionality. For information about identifying business requirements, refer to Chapter 4.

Assess Development Requirements

If the application is written in house, the development environment also must be migrated. This development environment must be assessed to ensure that a suitable replacement can be found for use in the new OS.

Tools such as text editors, compilers, and debuggers must be available for the application. Many development environments also use source code repositories that support multiple users modifying the source code at the same time. A development process is used to ensure that all changes are recorded and that people do not overwrite existing versions of source files.

Any changes introduced into the development environment will probably have an initial adverse effect on productivity because there will be a learning curve as people come up to speed. You will also have to determine training costs involved in preparing staff to work in the new development environment.

Test suites and scripts are also used in a development environment to ensure that changes or modifications to the application have not introduced errors or unwanted side effects. The testing process must be assessed to ensure that any tools or products used in testing the application are also available in the new environment.

Assess IT Operations Requirements

The management architecture will also need to be migrated to the new environment. An assessment of the existing management capabilities should be conducted to determine what will be required in the new environment.

The organization has some level of management capability, as defined in the Capability Maturity Model (CMM). Overall, IT management should conform to some methodology (ITIL, SunTone) and will use a number of products to assist in the collection of data and reporting of problems.

The new IT infrastructure will need to be integrated into this management framework. The existing management architecture will have to be assessed to ensure that products for the new IT infrastructure exist and can be integrated into the existing management architecture.

Assessing Skills Requirements

A key input into the selection of any migration strategy will be the skills of the existing IT staff. Training on new technologies can be expensive and can affect the overall cost of the migration project. Additionally, introducing new technology might result in decreased availability or productivity as people attempt to come up to speed on the new technology.

The existing skill level of the staff must be assessed, and their abilities should be an input to the migration strategy decision.

The assessment should focus on the skills at all levels in the organization: operators, administrators, and developers. You should develop a skills catalog that captures the abilities of the staff in terms of their familiarity with specific products and activities. You can then use this catalog when deciding on a migration strategy. Having this catalog enables you to identify gaps in skills and to develop a training curriculum to address any shortfalls.

Where appropriate, new hires or outside consultants can be used to fill gaps.