3.3.13       Retirement/Replacement

 

OBJECTIVES	·        Determine when a system needs to be retired or replaced. ·        Migrate to the replacement system with minimum disruption. ·        Remove the system from operation, gracefully terminating or transitioning its service. ·        Dispose of the retired system properly
Description	Eventually, almost every system will face retirement or replacement, no matter how well it was developed and maintained.   This step in the process describes how to determine the end of life for a system. The objective is to make this end of life a planned event so that a replacement system can be procured if necessary and the preparations can be made so the system retirement is graceful with minimum stakeholder impact.   When a system or subsystem needs to be replaced, a strategy must be developed to migrate to the new system gracefully, without interruption of service.   Following successful migration, the old system is deactivated and disposed of.
Context
INPUT Sources of Information	·        System performance measures ·        Maintenance records ·        Change requests/Change history
PROCESS Key Activities	·        Plan system retirement/replacement ·        Develop/procure the replacement system ·        Migrate operations to replacement system ·        Retire and dispose of current system
OUTPUT Process Results	·        System replacement plan ·        Operational replacement system ·        Archived documentation for current system

Overview

Systems are retired and removed from service for a variety of reasons: 

·        High cost of operations & maintenance

·        High cost of upgrades and changes due to system limitations

·        Technology obsolescence makes the system unsupportable.

·        Capabilities of the system are no longer needed

In all cases except the last, the system retirement must be planned well in advance so that a replacement system can be developed and deployed to meet continuing stakeholder needs with minimum disruption.  When a replacement system is in place, transition can begin from the system to be retired to the replacement system.  For critical systems that require very high availability, some period of parallel operation may be required during a transition period.

Regardless of the reason for the retirement of the system, you should make sure that everything is “wrapped up” properly (e.g., hardware and software inventory identified for disposal is audited, final software images are captured, and documentation is archived, etc.), the contract is closed properly, and the disposal of the system is planned and executed.

Risks to be managed:

Negative operational impacts due to retirement/replacement: The risk managed is that the system retirement has a negative impact on operational effectiveness, possibly impacting stakeholders, budget, and schedule.

 

Activities

This step represents the end of the system life cycle – the retirement and/or replacement of the ITS system. Characteristic of the whole systems engineering process is the planning of all events, and system retirement should be planned as well.

Plan system retirement/replacement

As the current system is operated and maintained, key data is collected that will inform a timely decision to consider and plan for retirement/replacement of the current system.  Operational performance of the system (Is it still meeting stakeholder needs?, What is system availability?, How is user satisfaction?), change requests in the queue (Can the system meet new and developing stakeholder needs?), and maintenance data (How is system reliability?, Are adequate replacement parts available?  Are maintenance costs increasing over time?) are collected and used to inform the decision to retire or replace the system. 

Perform Gap Analysis: Current system capabilities versus capabilities needed.  The trade studies process (see Section 3.4.5) can be used to evaluate the cost/benefit of upgrading the current system with replacement of the entire system or some major subsystem[s]. Can the current system evolve to meet the new needs? Is the technology that was used in the current system obsolete and no longer supportable? Have the operations and maintenance costs increased to the point where a replacement system is more cost effective?  To answer the last question, the trade study should include life cycle cost analysis, including the operations and maintenance costs of the current system, and replacement costs.  For comparison, the life cycle cost of the proposed replacement system is estimated. Will the replacement system have an improved cost/benefit ratio in operations & maintenance cost over its life? The replacement system should work better and cost less to maintain if the current system is truly approaching the end of its useful life.  Other issues to consider include vendor support of commercial products embedded in the current system and license costs. The trade study should also consider the quality of the current system.  For example, is the cost of documenting the current system prohibitively expensive, if documentation is not adequate?

Develop the replacement/retirement strategy.  If this trade study analysis supports system replacement, a strategy for system replacement is defined. This strategy may require the upgrade of facilities, floor space, air conditioning, communications, furniture, and other such facilities. Because some systems are safety critical, they have to be operational full-time. In this case, the new system would need to be deployed in parallel with the current system. In this case, a switch-over plan needs to be created to allow the legacy system to act as a back-up while the new system is being verified and validated. There is a cost and deployment impact from having both systems operate in parallel for that period of time. In other cases, where the system is not safety critical, removing the current system prior to the deployment of the new system may be more cost effective.

Develop/procure the replacement system

The same systems engineering process described in the previous sections is used to develop the replacement system.  This is another good opportunity to capitalize on the systems engineering documentation that was developed for the current system.  The current system documentation provides an important input to the replacement system documentation, since many of the same needs and requirements will likely carry over to the replacement system.  When defining the replacement system, it is also important to consider any lessons learned experienced in operating the current system.  The goal is to learn from issues encountered with the existing system so that the replacement system will not suffer from the same issues.  Following the systems engineering process, improved systems engineering documents that leverage the current system documentation will be developed for the replacement system:

·        New Concept of Operations-

·        Requirements

·        Design documentation

·        Verification plans

·        Support documentation on development, training, maintenance, and user manuals

Migrate operations to replacement system

As discussed in section 3.3.10, the replacement system is deployed and formally accepted, and operations transitions to the replacement system.  Depending on the criticality of the system being replaced, a period of parallel operation may be required, as defined in the replacement strategy.

Retire and dispose of current system

Planning for system retirement includes development of a disposal plan, which should include a complete inventory of all software and hardware, final system and documentation configurations, and other information that captures the final operational status of the system. This should include identification of ownership so that owners can be given the option to keep their equipment and use it elsewhere. It should also include how the system and documentation will be disposed, including an assessment and plan if special security measures should be in place or if there are environmental concerns that might dictate where the equipment should be disposed. You should also plan to erase the content of all storage devices to protect any personal data that might pose privacy concerns. The disposal plan should be reviewed and approved by all parties, including the agency or contractor providing O&M, the owner of the system (if different), and other key personnel.

The next activity is to deactivate the system.  execute the disposal plan and record the results. It’s also a good idea to hold a “lessons learned” meeting, including suggested system improvements. All recommendations should be archived for reference in future system disposals. The O&M contract should be officially closed out if one exists.

Tailoring This Step

The replacement strategy can be tailored for the project but factors that constrain this will be if the current system is critical  and needs to be operational nearly full time. Are there alternatives to the legacy system that can allow it to be inoperable until the new system is in place, verified, validated, and operational?

As with other steps, the amount of formal documentation that is necessary can be much reduced for simple systems.  For example, if the current system is a phone app and the replacement system is a new and improved phone app, “disposal” might simply entail uninstalling the old application.

Policy or Standard for Process Step

 The FHWA Regulation does not place specific requirements on this step, but if, as part of the replacement effort another systems engineering set of steps are initiated, then the requirements for those steps would apply.

Traceable Content

Table 12 shows how disposal records trace back to system requirements relevant to system disposal.

Table 12: Disposal Traceability

Traceable Artifacts	Backward Traceability To:	Forward Traceability To:
Disposal Records (Status of each disposal activity.)	System disposal requirements	N/A

 

Checklist

The following checklist can help answer the question “Are all the bases covered?” once the activities above have been planned or performed.  The checklist is not sufficient by itself.

R  Was a trade study done on the cost/benefit of upgrading the legacy system against the cost/benefit of developing or procuring a new system?

R  Did the trade studies include the operations & maintenance costs of the current and replacement system?

R  Is the replacement system well documented? Does it have a concept of operations, requirements, and documentation necessary to support operations and maintanence.

R  Is there a replacement strategy to switch out the current system with the replacement?

R  Have all of the affected stakeholders been involved in the replacement/retirement decision, and the planning and replacement strategy for the new system?