NOTE: This article will soon be updated to reflect the evolution of EUP to be based on
Disciplined Agile Delivery (DAD). Please stay tuned.
The EUP is comprised of five (or six) phases:
Figure 1. The Lifecycle for the Enterprise Unified
Process (EUP): 2013.
Pre-Inception (arguably the 0th phase)
The Inception Phase
The Construction Phase
The Transition Phase
The Production Phase
The Retirement Phase
When you look
at the diagram you see that the Enterprise disciplines include pre-project
efforts. The major activities of this "pre-phase" include:
The primary goals of the Inception phase are to achieve
stakeholder consensus regarding the objectives for the project and to obtain
funding. The major activities of the phase include:
Start the enterprise business model. This
information will be used to help scope out systems.
Portfolio planning. This includes the
identification, and then prioritization, of potential projects to be worked on
by your IT organization.
Enterprise architecture modeling. Your enterprise
architects may wish to put a "stake in the ground" and model some of the
enterprise architecture upon which project teams should base their system-level
Identification of reusable assets. Ideally project
teams should be able to look into their reuse repository to see which assets are
currently available for reuse.
Staff allocation. Some people will potentially be
hired, trained, and allocated to a project team before the project begins.
Process definition. We recommend Disciplined Agile Delivery (DAD).
To exit the Inception phase your team must pass the Lifecycle Objectives (LCO)
milestone. At this milestone, the stakeholders assess the state of the project.
They must agree on the following:
Define project scope. This includes defining, at a
high level, what is in the project. Equally important is to define what is not
in the project. This establishes the boundaries within which the team will
operate. This usually tales the form of a list of high-level features and/or a
use case model with 80% of the total use cases identified.
Estimate cost and schedule. At a high level, the
schedule and cost for the project are estimated. General estimates are used
for iterations in later phases, more specificity is used for the early
iterations in Elaboration. This should not be construed as meaning that the
entire project is planned out at this point. As with all planning, those tasks
that are to be completed in the near future are detailed more accurately and
with greater confidence while tasks further down the line are understood to be
estimates with larger margins of error. It has (finally) been recognized by
most in the industry that it is not possible to schedule an entire project at
its kick-off with any acceptable degree of confidence. The best that can be
done is to plan for the near term accurately and the longer term as best as
Define risks. The risks to the project are first
defined here. Risks are an important concept in a RUP project. The list of
risks is a living compilation that will change over time as risks are
identified, mitigated, avoided and/or materialize and dealt with. Risks drive
the management of the project, as the highest priority risks drive the
scheduling of iterations. Higher priority risks, for example, are addressed in
earlier iterations than lower priority risks. Putting off addressing a high
priority risk puts the entire project in danger. It is therefore critical to
know what your risks are and that you attack them head on.
Develop the business case. A business case
defines from a business perspective why the project is (or isn’t) worthwhile.
If the business case shows that the project is not worthwhile, the project
should be cancelled. The business case should also show how the project
maps to the enterprise business model.
Prepare the project environment. This includes
reserving workspace for the team, requesting the people that will be needed,
obtaining hardware and software that are needed immediately, and compiling a
list of anticipated hardware and software that will be needed later. In
addition, the software process, such as Disciplined Agile Delivery (DAD), to be followed by the project is selected here.
If the stakeholders agree that the project meets the above criteria, the
project moves to the Elaboration phase. If the project fails in any area above,
the project may be re-directed or cancelled outright.
The focus of the Construction phase is to develop the system to the point
where it is ready for pre-production testing. In previous phases, the majority
of the requirements have been identified and the architecture for the system has
been baselined. Emphasis shifts now to prioritizing requirements and completing
their specification, analyzing them, designing a solution to satisfy them, and
coding and testing the software. If necessary, early releases of the system are
be released, either internally or externally, to obtain user feedback.
To exit the Construction phase your team must pass the Initial Operational Capability (IOC) milestone. At this milestone, the stakeholders must agree on the
- Scope concurrence. The stakeholders reach agreement as to the
scope of the project.
- Initial requirements definition. There is agreement that the right
set of requirements have been captured, even if just at a high level, and
there is a shared understanding of those requirements.
- Plan concurrence. The stakeholders agree with the initial cost and
- Risk acceptance. The risks have been identified, assessed, and
acceptable strategies to address them have been identified.
- Process acceptance. The development process has been initially
tailored and agreed to by all parties.
- Business case. The business case shows that the project makes
sense from a business perspective.
- Project plan. Adequate plans are in place for the next phase
- Portfolio compliance. Does the scope of the project fit well
into your organization's overall project portfolio?
If the stakeholders agree, the project moves to the Transition phase. If the
project fails in any area above, the project may be re-directed or cancelled.
The Transition phase focuses on delivering the system into production. There
may be extensive testing that takes place during this phase, including beta
testing. Fine-tuning of the product takes place here as well as rework to
address significant defects (your stakeholders may choose to accept the
existence of some known defects in the current release).
The time and effort spent in Transition varies from project to project.
Shrink-wrapped software entails the manufacturing and distribution of software
and documentation. Internal systems are generally simpler to deploy than
external systems. High visibility systems may require extensive beta testing by
small groups before release to the larger population. The release of a brand new
system may entail hardware purchase and setup while updating an existing system
may entail data conversions and extensive coordination with the user community.
Every project is different
To exit the Transition phase your team must pass the Product Release (PR)
milestone. At this milestone, the stakeholders must agree on the following:
- System stability. The software and supporting documentation are
acceptable (stable and mature) to deploy the system to users.
- Prepared stakeholders. The stakeholders (and the business) are
ready for the system to be deployed.
- Risk acceptance. The risks have been assessed to ensure they have
been properly understood and documented and strategies to handle them are
- Cost and estimate acceptance. The current expenditures are
acceptable and reasonable estimates have been made for future costs and
- Project plan. Detailed iteration plans for the next few Transition
iterations, as well as a high-level project plan, are in place.
- Enterprise standards compliance. Do the artifacts produced by
the team comply to the appropriate enterprise standards?
If the stakeholders agree, the project moves to the Production phase. If the
project fails in any area above, the project may be re-directed or cancelled
(some projects are such disasters that you don't want to even install them).
The focus of the
Production phase is the operations,
support, and change management of new requirements and defects. The
Gartner Group reports that 75% of the costs of software are incurred after
systems have been developed and deployed. A complete software process must take
into consideration the issues of operating and supporting software after
deployment. The Production phase of the EUP defines a process to do that.
The objectives of the Production phase are:
- Business stakeholder acceptance. The business stakeholders are
satisfied with and accept the system.
- Operations acceptance. The people responsible for operating the
system once it is in production are satisfied with the relevant procedures and
- Support acceptance. The people responsible for support the system
once it is in production are satisfied with the relevant procedures and
- Cost and estimate acceptance. The current expenditures are
acceptable and reasonable estimates have been made for future costs.
The primary activities of the Production phase include:
- Ensure that the system is available to end users.
- Modify the system to address minor defects.
- Support users in using the system.
- Manage defect reports and enhancement requests.
Most of these tasks occur in the Operations and Support discipline, a new
discipline introduced by the EUP. Existing RUP disciplines such as
Requirements, Analysis and Design, Implementation, and Configuration and Change
Management are extended to support the needs of the Production phase.
Production phase ends with the
Release Replacement (RR) milestone. At this
milestone, you must achieve the following:
Operate the system; ensuring that it is available to
Migrate the system to different hardware configurations
Monitor the system, including jobs, logs, and supporting
systems, ensuring that it is performing properly.
Back up and restore data as required.
Perform periodic cleanup tasks such as removing temporary
files, archiving old data, and compressing storage.
Execute failover strategies as necessary.
Respond to user requests for help using the system.
Record user defect reports and enhancement requests.
Assign new requirements to future releases.
Make and deploy fixes.
The details of the
Production phase will differ from system
to system. Shrink wrapped software, for example, will typically not require
operational support personnel but will require a helpdesk to assist users.
Internally systems deployed into data centers will require an operations staff
to run and monitor the system. The details of the
Production phase will change
from organization to organization. The EUP, like the RUP, requires each
organization to tailor it to meet their specific needs.
The focus of the Retirement phase is the successful removal
of a system from production. This is a serious issue faced by most
organizations today; as legacy systems are turned down and new systems replace
them, you must complete this effort successfully and without a major
interruption to their daily organizational business needs. If you have tried
this in the past, you know how difficult it can be.
Software systems do not last forever. Eventually, they
become obsolete or superceded by other systems and must be removed (often
referred to as "sunsetting”). Systems are removed from production for several
- System release removed or scheduled for removal. This can happen for one of several reasons.
First, a new release of the system is deployed into production. Second,
the decision could be made to retire the system, thus it moves into the
retirement phase. Third, your IT organization ceases operation.
- Stakeholder acceptance. The relevant stakeholders agree that
the system is to be replaced.
The objectives of the Retirement phase are:
They are no longer needed for the current business
model. For example, legislation was passed requiring a system update – and
now that legislation has been repealed.
They are obsolete (for example, systems created to handle
the Y2K mess).
The system is being replaced. For example, it is common
to see homegrown systems for human resource functions being replaced by
commercial off-the-shelf (COTS) systems such as SAP or Oracle Financials.
Activities of the retirement phase include:
- Complete the removal of the system.
Ensure minimal interruption to users.
Ensure minimal impact to business operations.
The Retirement phase ends with the Release Retirement (RET)
milestone. At this milestone, you must achieve the following:
- A comprehensive analysis of the existing system to identify its coupling
to other systems.
- A redesign and rework of other existing systems so that they no longer
rely on the system being retired.
- Transformation of legacy data – perhaps via
– because it will no longer be manipulated or required by the system being
- Archive the data previously maintained by the system so that is no longer
needed by other systems.
- Manage the configuration of the removed software so that it may be
reinstalled at some point in the future (easier said than done).
- System integration test of the remaining systems to ensure that they have
not been broken.
- Communicate with the user community to ensure a smooth retirement,
including beta testing.
System retirement is not a simple effort; it needs a defined process, and is
usually a project within its own right. Retirement of a system is a distinct
possibility within all organizations today. If this is something facing your
team today it should be an explicit part of the overall lifecycle. The RUP is a
great start; however, it needs to be extended to meet the real-world needs of
organizations – both today and in the future. The Enterprise Unified Process
was developed to address this exact need.
- System release removal. This includes: hardware and software, scheduled
jobs, and archived data.
- Updated documentation. Documentation must be updated; this includes
system, operational, and enterprise architecture.
- Stakeholder acceptance. All stakeholders must have been
notified and signed-off and understand the system is removed from production.