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 StatementAs 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
Table 4-3. RSS System Factors
SolutionThe 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 TeamAs 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 TeamThe 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 TeamThe 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 EstimationThe 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. RisksBarry 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.
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. BenefitsThe 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
|