Techweb
CMP Media / Optimize - Business Strategy & Execution for CIOsCMP MediaOptimize
Optimize Magazine DisciplinesExpertsGap AnalysisDiscussionsWhite PapersExecutive Events Information Week Optimize Magazine
Optimize Magazine
Optimize Magazine
Tuning Up Legacy Systems
Breaking the cycle
Email
Reprint
Discuss
 Story contents


The bigger question that CIOs face is this: What will prevent the new system from suffering the same fate as the system it replaced? The solution is to avoid creating new legacy systems and to modernize the existing legacy systems. But how?

Preventing systems from slowly becoming legacy systems requires active sustainment. The goal, in terms of the information-system life cycle, is to prevent the project from "flat-lining" and consequently requiring a replacement effort. Sustainment is qualitatively different from maintenance in that the maintainability and evolvability of the code must be retained even as modification requests are satisfied. Sustainment means taking the time to repair defects correctly and not simply patching the code. It may also require technology refresh and architectural evolution—for example, upgrading from "green screens" to a Web-based interface or adopting a distributed architecture.

To avoid obsolescence, the sustainment budget must exceed that used for simple maintenance and let the IT team keep pace with changing technology and evolving business needs. The system must also evolve in a way that maintains its architectural integrity or adapts the architecture to new requirements. The potential for success in system sustainment can be greatly improved, of course, by building systems from the ground up with sustainability in mind.

To accomplish sustainment goals, maintenance efforts should be punctuated with modernization projects, such as revamping an existing user interface, targeting a system to a new platform, or replacing a hierarchical database with a relational database-management system (see sidebar, Sustaining A Software System). Though not as disruptive as replacement, modernization has risks and is best accomplished with a risk-managed approach using portfolio analysis.

Risk-management practices continuously assess what can go wrong, determine what risks are important, and implement strategies to deal with risks before they emerge as problems. Such assessments are an integral part of the spiral development process.

A precondition for minimizing the modernization risk is a portfolio analysis that evaluates each system and determines an appropriate evolution strategy. The analysis measures the technical quality and business value for a set of systems, and then evaluates the set against the measures. Business value measures the number and criticalness of the business goals supported and the degree to which these goals represent core competencies of the business—a task that must be accomplished in conjunction with the CIO's business counterparts. The technical-quality measures might include availability, evolvability, maintainability, performance, security, usability, and other system qualities. The Software Engineering Institute at Carnegie Mellon University recently developed measures for maintainability and evolvability. Also, tools from companies such as Klockwork Inc. can measure aspects of these qualities. Klockwork tools work primarily with C++ and Java.

Legacy systems are evaluated against these measures and positioned on a portfolio-analysis grid, such as the one shown in the chart. The quadrant in which each system appears suggests an appropriate evolutionary strategy:

  • Systems with low business value and poor technical quality are logical candidates for replacement with commercial packages. These systems may be used for payroll, human resources, or similar noncore services.

  • Systems with high technical quality and low business value can be maintained with continued low-level maintenance activities.

  • High-quality systems with high business value should be actively sustained to avoid degradation.

  • Systems with high business value and low technical quality are candidates for modernization or replacement.

    Also consider the real organizational or resource issues that can significantly increase the risk to a modernization effort. Typically these include available staff, cost, politics, schedule, technical skills required, training of the development staff, training personnel to use the modernized system, and user acceptance of the modernized system.


    Permission provided by:
    http://www.awprofessional.com/titles/0321118847


    After performing the portfolio analysis and identifying modernization issues, the CIO can select and prioritize candidate systems and develop an overall modernization strategy. The portfolio analysis should be re-evaluated annually or as dictated by business changes.

    Increased and simultaneous investment in multiple core systems isn't without risks. However, it acknowledges that certain information systems are inseparable from and must evolve along with the business. Sustainment lends itself to lower risks by avoiding the wholesale replacement of systems, minimizing both the disruption of services and irritation of users.

    There are obstacles, however. CIOs may have difficulty securing the funds necessary to sustain systems at required levels. Without adequate funds, you may need to eliminate one or more nonessential systems to sustain the rest. Ideally this situation can be avoided by not letting systems degrade to the point where modernization costs exceed replacement costs, leaving replacement as the only reasonable option. Resources can then go into sustainment and modernization projects that retain the existing investment in these systems.

    Staff issues can arise, and CIOs may have concerns about software developers who feel stuck in the same job. However, if the systems are upgraded with changing technology, rather than minimally maintained, the developers will be continually challenged to grow along with the system. Some developers will be motivated to learn new skills and become change leaders. Others will feel more comfortable sustaining the older technologies. As the technology base evolves, these developers will eventually follow.

    It may also be useful to hire consultants who specialize in technologies that are being incorporated but are poorly understood by the development team. Consultants shouldn't become permanent fixtures. Instead, assign an individual from your organization to work with and learn from the consultant so your department can sustain the system organically after the consultant leaves (see The Incredible Shrinking Legacy Workforce).

    Software sustainment is designed for the company's long-term health, not for any short-term effect. As the Greek war historian Thucydides wisely said, "The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it." While sustainment may be costly and unpleasant, a lack of sustainment carries a higher penalty.

    Robert Seacord is a senior member of the technical staff at the Software Engineering Institute at Carnegie-Mellon University and co-author of Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices (Addison-Wesley, 2003).



  • Optimize Magazine
    Optimize Magazine Marketplace (Sponsored Links)

    Buy a Link Now


    Optimize Magazine Optimize Magazine Optimize Magazine Optimize Magazine Optimize Magazine
    Optimize Magazine Optimize Magazine
    Optimize Magazine