4.6 The RSS Business Case

The business case for RSS was presented to management, and a tentative funding plan was established. However, funds were released only for the initial modernization planning phase. Additional funding had to be obtained for later increments , based on the success of the initial phase.

In this section, we present highlights of the RSS business case. In particular, key arguments included the high maintenance and support costs for the Unisys mainframe, the lack of asset visibility, and the need for timely reports based on consolidated data.

Problem Statement

As discussed in previous chapters, RSS is a critical enterprise information system that cannot be easily replaced or eliminated. Unfortunately, RSS is also at the end of its life cycle, as years of minimal maintenance activity have left the system in a state such that it can no longer be effectively maintained .

In both understanding and communicating the problem, it is helpful to assess environmental as well as legacy application factors. Table 4-2 lists environmental factors contributing to problems with the existing system; Table 4-3 addresses system factors.

Table 4-2. RSS Environmental Factors

Factor	RSS Environment
Supplier stability	The Unisys mainframe market continues to contract each year.
Failure rate	Changes to the database schema have not been allowed for 5 years, because the system is too brittle to handle these changes.
Age	RSS has evolved over 30 years in a relatively uncontrolled manner.
Support requirements	Support costs for Unisys software continue to increase as the market for this software contracts.
Maintenance costs	The cost of maintaining the Unisys mainframe operational is high and increasing.
Interoperability	RSS lacks interoperability with wholesale and other systems that provide total asset visibility.

Table 4-3. RSS System Factors

Objective	Sample Quantifiable Benefit Metrics
Understandability	As a result of the moratorium on schema changes, the programming staff has been using FILLER fields to store data, adding to the overall lack of comprehensibility of the system.
Documentation	User documentation is adequate, but system architecture and design documentation is lacking. Some documentation of the existing database schema exists.
Data	The schema for the system has evolved over time, resulting in a large number of duplicate fields.
Performance	Performance of the existing system is adequate.
Programming language	Replacing COBOL programmers is difficult because COBOL is not a core course in colleges anymore, and students do not want to learn it, because jobs for COBOL are limited.
Configuration management	Software is under adequate configuration management control.
Test data	Testing of the system had been adequate, although test data is not preserved for use in regression testing, for example.
Personnel skills	Seventy percent of the programming staff are within 5 years of retirement.

Solution

The solution is incrementally developing and deploying a modernized RSS system over a 7-year period. An overview of the RSS modernization schedule to the release of the first increment is presented in Figure 4-1. These tasks are organized by team and are described next . One of the goals of the modernization planning effort is to have a detailed schedule for each increment.

Figure 4-1. Modernization schedule for RSS

Architecture Team

As shown in Figure 4-1, the architecture team is responsible for the SRF corporatewide architecture. An initial version of the SRF is already defined at the start of the modernization effort. Two minor version upgrades are anticipated before modernization planning is finished. A major version upgrade is expected by the time the first increment is deployed. It is assumed that the RSS migration planning and increment 1 development will influence the architectural development and that changes to the architecture will conversely serve as a source of instability in the RSS development effort. However, the amount of influence exerted in each direction depends on other concurrent development efforts and their influence on the architecture, technology advances, marketplace product releases, and organization politics.

Development Team

The development team is responsible for the modernization plan, the development of the RSS architecture in compliance with the SRF, and the development and deployment of modernized components. The maintenance team is in charge of creating adapters so that the modernized components can interact with the components of the legacy system that have not been modernized, as well as the usual maintenance tasks. Both the maintenance and development teams are synchronized for each increment because they are collaborating to deliver a system that consists of modernized and legacy components . The architecture team is not expected to be synchronized with the development and maintenance teams , because they are organizationally driven.

Maintenance Team

The maintenance team has been in place for more than 30 years. Figure 4-1 shows the list of activities to be performed by this team before the first increment. At the start of the effort, the team completes work on a Web-enablement effort, which was explained in Chapter 2. Following the Web-enablement effort, the maintenance team begins a series of activities to simplify and support the overall modernization effort. The Reports activity refers to migrating data required for report generation to an Oracle database and using Oracle Discoverer to generate reports, as also explained in Chapter 2. This activity eliminates a large amount of report-generation code that otherwise might need to be ported. The Code Reduction activity eliminates code that is no longer required, so that this code does not need to be ported either. Following these activities, the maintenance team begins to work more closely with the development team to develop an initial increment that deploys both legacy and modernized components.

Cost Estimation

The cost of modernizing RSS is estimated at approximately $108 million over a 7-year period. This includes development team and maintenance team activities but does not include the cost of the architecture team, which is covered elsewhere.

This rough order-of-magnitude estimate was created by project management as part of the business case preparation. To develop this rough estimate, the total lines of code (LOC) for the legacy system was converted to the equivalent LOC in the new implementation language and allocated evenly across the planned number of increments. Cost models were used to estimate the cost for requirements analysis and architecting for the whole system; the cost for designing, coding, and testing for each increment; and the cost of testing for the whole system, as each increment was going to be deployed. An estimate of 20 percent was added to the estimated cost to account for the effort in constructing adapters for each increment and for the one-time migration of the legacy database. Other costs presented were hardware equipment, network infrastructure, training, development tools, software licensing, support, and staff.

Risks

Barry Boehm has stated that all software projects benefit from identifying risk elements during early stages [Boehm 91]. A risk evaluation involving the various stakeholder groups was performed for RSS. Risks were stated using the risk statement structure suggested by the Software Risk Evaluation (SRE) method developed at the SEI [Williams 99]: a condition ”something that is true or accepted as true; a separator ”an arrow, a semicolon, or a linking phrase; and a consequence ”something that may occur as a result of the condition.

Twenty-six identified risks for incremental development and deployment for RSS were identified and prioritized according to impact on the project if the risk materializes. The top six risks identified follow.

1. In an incremental development and deployment, legacy and modernized components coexist, and adapters need to be built for communication between the two systems; the effort assigned to adapter construction may be underestimated, affecting cost and schedule.

2. RSS is a complex system that has grown over 30 years in an unorganized manner; coupling between the various modules in the system may be high, increasing the number of necessary adapters.

3. An incremental approach implies incremental funding; the funding may end before the modernization is complete.

4. Interactions between legacy and target software technologies are not well understood ; target architectures and component ensembles may be infeasible.

5. Users have a perception of system performance given by the current legacy system; use of adapters for communicating between legacy and modernized performance might impact performance and cause user dissatisfaction.

6. The development team is not familiar with COBOL, and the maintenance team is not familiar with the new technologies; communication problems may occur, and assumptions may be made about each team's "knowns" and "unknowns."

Many of these risks are significant both in their probability and their potential impact on the modernization effort. These risks need to be considered as part of the business case.

Benefits

The business case for RSS presented both cost reduction and cost avoidance to justify the modernization, with an emphasis on cost benefit. The major cost- avoidance argument addressed the high and increasing maintenance costs for the Unisys platform. At the current growth rate, these costs would exceed 100 percent of the RSS maintenance budget within 4 years. Rising maintenance costs alone make a compelling argument for migrating RSS. However, the overall modernization goals are more ambitious and include rearchitecting the system.

The justification for rearchitecting the system derives largely from the inability to maintain the existing code. This is critical because the system must evolve to support changing business practices. The difficulty in maintaining the system is apparent in many of the metrics maintained in the defect-tracking database. For example, more than 60 percent of the maintenance effort on the legacy system is spent correcting defects caused by earlier defect fixes.

Additional benefits to RSS modernization that lend weight to the business case include

• Improved functionality: The RSS system will provide real-time visibility to all corporatewide data, including stock at all retail locations, warehouses, and in transit. "Total asset visibility" will improve decision making and lead to higher customer satisfaction and decreased operational costs.

• Improved quality: High-quality systems will result from the use of modern methodologies and technologies.

• Improved maintainability: The migration of each COBOL program will target code structure improvement and explicit interfaces. Eliminating dead code will also reduce the amount of code to maintain.

• Evolvable system: An evolvable system can adapt as business rules change and new functionality is required. With an evolvable architecture, it will also be easier to incorporate new technologies.

• Increased productivity: Staff will concentrate on evolving the system instead of working around the inflexibility of the current system.

• Easier staffing: It is easier to find qualified staff to work with the modern technologies.