Extending the RUP with a Retirement Phase
|The final phase of the Enterprise Unified ProcessTM (EUP) lifecycle is Retirement, as shown in Figure 1. The goal of this phase is the removal of a system release from production, and occasionally even the complete system itself, an activity also known as system decommissioning or system sunsetting. Retirement of systems is a serious issue faced by many organizations today as legacy systems are removed and replaced by new systems. You must strive to complete this effort with minimal impact to business operations. If you have tried this in the past, you know how complex it can be to execute successfully.||
System releases are removed from production for several reasons, including:
The system is being complete replaced. It is not uncommon to see homegrown systems for human resource functions being replaced by COTS systems such as SAP (www.sap.com) or Oracle Financials (www.oracle.com).
The release is no longer to be supported. Sometimes organizations will have several releases in production at the same time, and over time older releases are dropped.
The system no longer needed to support the current business model. A organization may explore a new business area by developing new systems only to discover that it is not cost effective.
The system is redundant. Organizations that grow by mergers and/or acquisitions often end up with redundant systems as they consolidate their operations.
The system has become obsolete.
In most cases, the retirement of older releases is a handled during the deployment of a newer version of the system and is a relatively simple exercise. Typically, the deployment of the new release includes steps to remove the previous release. There are times, however, when you do not retire a release simply because you deploy a newer version. This may happen if you can not require users to migrate to the new release or if you must maintain an older system for backward compatibility.
The final retirement of a system can be a different matter. In this case you cannot rely on a newer version of your system being available to supply the functionality which you are retiring. Instead this functionality, and the data which supports it, is either implemented by another system (often in a very different manner to the end user) or is completely removed. The implication is that you may have significant rework to do in order to update the other systems which interface to this functionality. Final retirement of a system is typically executed in parallel with the implementation of other system(s) which are replacing it, such as when an internally-developed system is replaced by a commercial off the shelf (COTS) solution. In these situations the two efforts must be closely coordinated and may even be staffed by the same personnel.
Figure 1. The EUP lifecycle.
Figure 2 depicts the workflow for the EUP Retirement phase.
Figure 2. The Retirement phase workflow.
The main activities of retirement are:
Analyze system interactions. Most systems do not exist in isolation but rather interact with others systems in some fashion. As part of your retirement effort, you must identify the interactions, analyze them, and address each one via legacy integration modeling.
Determine retirement strategy. Your strategy depends on your situation. First, if this is a new release of your system, you may need to perform simple data conversions, perhaps applying the collection of database refactorings implemented during the development cycle for this release as well as the new version of the application code. Second, when replacing an system with one developed in-house the team developing the replacement system will be responsible for architecting, designing, and implementing the interactions. They should do so following guidance from your enterprise architects, and the results of the legacy analysis, and seek to minimize the impact on other systems. Third, when replacing with a COTS system you will likely want to extend the COTS product, implying that you may opt to engage the COTS vendor to develop the additionally functionality you need. Fourth, completely retiring a system is the hardest case because you need to rework the external systems and may even cause the retirement of other systems because you have removed critical functionality which they cannot do without. You must work with the owners of the other systems and assist them in finding other sources for the information they need.
System removal. This is often a complex task, as you must migrate and convert data, turn off access and remove all vestiges of the retiring system, and update all the others systems that interacted with the retiring system. It’s a good idea to take a complete backup of your system before you begin just in case you need to recreate the system in a hurry.
From the point of view of the EUP disciplines, the following occurs:
Although it is a phase in the EUP most retirement efforts are managed as a separate project. Simple systems are usually retired within a single iteration, during which the stakeholders are notified that the system is going away, access is turned off in an orderly fashion, and the system and documentation are removed. Of course, for non-trivial systems, this still entails a fair amount of work. Notifications must go out to all stakeholders, plans for alternate means of continued functionality must be made, and all vestiges of the systems must be found and removed.
Large, complex, or heavily used systems may require multiple iterations. It’s not uncommon to retire systems that handle critical business functionality by running the system to be retired and the system that is replacing it in parallel for a period of time to ensure that the functionality is working properly in the new system. Only when the stakeholders are satisfied that the new system is satisfactory is the old system shut down. This provides the ability to verify that the new system is functionality appropriately by comparing it to the results of the old systems and also the option to quickly revert back to the old system if something goes wrong. It may add significant costs, however, in terms of hardware, support, and time spent running multiple systems in parallel and is often done only for crucial systems.
Another variation is to retire the system incrementally – just as systems are developed incrementally, they’re often retired incrementally too. Portions of the systems are removed in parallel with the addition of similar functionality in other system(s). This can be much easier to manage that attempting to do it all at once, although it may take longer to do. The impact on users must be considered when attempting this – what is easier on them to retire it all at once or would they prefer to be migrated to the new system slowly?
As you see in Figure 3 the Retirement phase ends with the Release Retirement (RET) milestone. The RET milestone determines whether the system has been successfully removed. At this milestone, you must have answers to the following questions:
What are the impacts to the business resulting from the system removal? Are they acceptable to the stakeholders?
Figure 3. The phases and milestones of the EUP.
This site owned by Ambysoft Inc.