4.4 RSS Requirements

In the case of RSS, specific requirements and constraints are separated into three categories: new functionality, architecture compliance, and process, with incremental development and deployment being the greatest process constraint.

New Functionality

The management team requires access to timely data. With the current system, for example, it is impossible to obtain the number of stock items available in real time. We refer to this requirement for access to corporatewide data as total asset visibility.

Management also needs timely reports based on consolidated data. This situation was partially resolved by the creation of the Oracle database that consolidates the data from the 90 DMS databases, as explained in Section 2.2. Nevertheless, it is far from being ideal. Data is not necessarily up-to-date, as the database is updated only once a day. Also, the Oracle database schema still more or less corresponds to the legacy database schema design, which makes it difficult to understand relationships between data elements and is not an efficient relational database design.

As in any other organization, user groups are dependent on RSS for their work. These groups are generally satisfied with the functionality of the system ”in their words, "it is not optimal, but it works." Given this satisfaction, it is obvious that they want current functionality replicated in the new system. They do not want any gaps in its availability. On the other hand, they are continually faced with the difficulties of requests for improvements. Some users even have spreadsheets or small databases to help them cope with requirements that the system cannot satisfy . This is seen as overhead. The user group also wants adequate training, user's guides, reference manuals, and on-line help systems in place before fielding the system.

Architecture Compliance

The retail organization modernizing RSS mandates the use of the Standard Retail Framework (SRF) in all modernization and development efforts. Developed by the architecture team, the SRF is a software architecture based on existing industry standards from the Open Applications Group, Sun Microsystems, and other industry groups. At a high level, the architecture requires defining and implementing large-grained business objects that represent chunks of functionality using Java and other open-systems technologies and communicating using asynchronous message passing.

SRF defines several constraints for RSS to promote interoperability and to allow for the reuse of products, code, and knowledge throughout the organization. Ideally, the use of industry standards in the SRF will also increase the likelihood of finding commercial-off-the-shelf (COTS) products that implement the various business objects.

Architectural compliance is a major concern for both the development and maintenance teams . The development team is concerned with the learning curve for the technologies incorporated in the SRF. The team is also concerned with its feasibility and compatibility with the legacy RSS system and requirements. The maintenance team is concerned with its unfamiliarity with the technologies mandated by the architecture team and lack of confidence that the architecture will perform adequately.

Incremental Development and Deployment

Incremental development and deployment is a constraint imposed by management but is also supported by the development team as a viable approach. In general, this approach deploys new components before completing the entire system. To maintain existing functionality during incremental development, it is necessary to combine elements from the legacy system with the modernized components . The deployed system exists in this transitional stage ”partly modernized and partly legacy ”immediately following the initial deployment and until the final release. In a large modernization effort, this transitional period may last several years . Because the system must remain fully operational, it is necessary to achieve required system qualities in each deployment.

In this approach, funding is provided by increment. The results of each increment help justify funding for the next increment. If it is not demonstrating sufficient progress, the modernization effort may be terminated at the end of an increment. Many organizations, having failed in previous modernization efforts ”our case study being no exception ” mandate an incremental development and deployment to mitigate risks. In theory, incremental development and deployment is more expensive because of the need to verify and validate each deployment. In practice, however, these costs can be overshadowed by a catastrophic failure of a big-bang deployment.

Incremental deployment plans are driven primarily by complexity and technical feasibility. It is critical to ensure that the functionality, reliability, and performance of the system are not diminished after an incremental deployment, especially because the project could be terminated after any increment. Integrating legacy code alongside modern components requires careful planning and execution but can be an effective risk-reduction strategy.

Modernization Goals

The modernization goals for RSS were defined with input from the stakeholders. These goals guide the development of the modernization plan.

Minimized Development and Deployment Costs

Fielding modernized components alongside legacy code requires adapters, bridges, and other scaffolding code that will be discarded after the final increment. Scaffolding code represents an added expense, as this code must be designed, developed, tested , and maintained during the development period. Minimizing the development of scaffolding code helps minimize overall development costs.

Schedule

The modernization strategy should seek to minimize the time needed to develop and deploy the modernized RSS. Additionally, the approach should allow the RSS to be developed on a predictable schedule.

Quality

The two issues regarding quality are: (1) the quality of the final, end-state system once the RSS modernization effort has been completed, and (2) the interim quality of the system after each increment. The final system should be easy to maintain and implemented around technologies that are not already obsolete. Each interim release should also improve the overall quality of the system.

Given the length of time required to complete the modernization, there will be many opportunities for the modernization effort to lose funding, be redirected, or take on a new focus. It is important that each fielded increment improve the overall quality of the system, because there is always the possibility that each increment will be the last.

Minimized Risk

Risks occur in many different forms, and some risk is acceptable if managed and mitigated properly. Because of the overall size and investment required to complete the RSS development, it is important that overall risk be kept low. To this end, the RSS componentization strategy should apply tried-and-proven techniques when possible and lower-risk approaches when some risk is necessary to achieve overall system goals.

System Performance

Because the RSS is replacing an existing system, users have expectations about performance. Although RSS modernization includes modernizing hardware as well as software, it is easy to negate hardware performance gains with poorly designed software. Therefore, the componentization strategy must ensure that user performance expectations are met or exceeded. Proper planning of the modernization effort and early prototyping help minimize performance and response-time issues. As a first step, the development team must benchmark the legacy system to determine its performance and response times.

Minimized Complexity

Depending on how lines of source code are counted, the RSS consists of up to 1.8 million lines of legacy COBOL code developed over 30 years. The size of the RSS by itself is a major source of complexity. It is therefore critical to minimize overall system and development complexity. Managing the complexity of the development effort may be the single largest factor affecting the viability of the overall RSS modernization effort.