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.
Table of Contents
System releases are removed from production for several
- Major activities
- Managing retirement efforts
- The release retirement milestone
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: 2013.
Figure 2 depicts the workflow for the EUP Retirement
Figure 2. The Retirement phase
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
- 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).
- 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.
- 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.
- 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.
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
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:
- 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
- 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
Figure 3. The phases and
milestones of the EUP.
What are the impacts to the business resulting from the
system removal? Are they acceptable to the stakeholders?
Was the system successfully removed?