Retirement Phase: Enterprise Unified Process

Table of Contents

1. Overview
2. Major activities
3. Managing retirement efforts
4. The release retirement milestone
5. Translations

1. Overview of the Retirement Phase

System releases are removed from production for several reasons, including:

1. 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).
2. 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.
3. 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.
4. The system is redundant. Organizations that grow by mergers and/or acquisitions often end up with redundant systems as they consolidate their operations.
5. 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: 2013.

2. Retirement Phase: Major Activities

Figure 2 depicts the workflow for the EUP Retirement phase.

Figure 2. The Retirement phase workflow.

The main activities of retirement are:

1. 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.
2. 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.
3. Update the documentation. You will need to update a wide range of documentation, including your operations and support procedures, enterprise architecture models, system portfolio documentation,  administration documentation, and system overview documentation (to note that it’s been retired).
4. Test. You must test your migration tools in a similar manner that you would test a system during the Transition phase. If you are following the evolutionary approach of the EUP you will be testing your migration and removal tools as you develop them. While it is desirable, you may not have the luxury of a test environment that supports all of your system, including all your data. If that is the case, make sure that the data you do have is a representative sample of the entire system.
5. Migrate users. You will most likely not be able to simply turn off access to a system one day and be done with it. You must accommodate your end users by notifying them appropriately of the upcoming retirement and assisting them in migrating to other systems.
6. Archive. The existing data, code, documentation, and other system artifacts must be properly archived so that it may be restored at a future date if required.
7. 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:

• Analysis and Design. If the functionality of the system is to be provided by other system(s), then analysis and design of that effort is done. This typically includes a comprehensive analysis of the existing system, often called legacy analysis, to identify its coupling to other systems. The redesign and rework of other existing systems so that they no longer rely on the system being retired must be done. In addition, programs to remove the system and its data are designed.
• Implementation. Programs to remove the system and its data are developed. As necessary, changes are made to other systems that interface with the system to be retired and data are archived or migrated to other locations.
• Test. Programs to be used to retire the system are tested, as are systems that interfaced with the system after those systems are updated.
• Deployment. One of the final steps in the Retirement phase is the actual removal of the system. This entails removing the code and the data, translating remaining legacy data as appropriate, and deleting any scheduled jobs (including backups).
• Configuration and Change Management. Change requests and defect reports received during the Retirement phase against the outgoing system are typically not accepted although they may be reassigned to alternate systems. Fixes are rarely applied to a system that is slated to be removed and enhancement requests may be rejected entirely. The final configuration of the system to be retired is archived appropriately.
• Project Management. Activities in the retirement phase are managed, just as with other phases.
• Environment. Support environments are modified as needed during the Retirement phase.
• Operations and Support. The release to be retired must still be operated and supported until it is finally removed. Support is typically minimized during this phase as users are encouraged to discontinue use of the retired system.
• Portfolio Management. Portfolio managers must assess the impact of the removal of a system on the overall enterprise portfolio and react accordingly. They may examine the loss of major functionality, for example, and approve projects that provide something similar.
• Enterprise Architecture. The enterprise architects must update their “as is” models to reflect the fact that the system has been removed.
• Enterprise Administration. Retiring systems often require configuration changes to the enterprise to reflect the removal of the system.

3. Retirement Phase: Managing Retirement

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?

4. Retirement Phase: The Release Retirement Milestone

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?
• Was the system successfully removed?

Figure 3. The phases and milestones of the EUP (click to enlarge).