Phases of the Enterprise Unified Process

1. Pre-Inception (arguably the 0th phase)
2. The Inception Phase
3. The Construction Phase
4. The Transition Phase
5. The Production Phase
6. The Retirement Phase

1. Pre-Inception

When you look at the diagram you see that the Enterprise disciplines include pre-project efforts. The major activities of this “pre-phase” include:

1. Start the enterprise business model. This information will be used to help scope out systems.
2. Portfolio planning. This includes the identification, and then prioritization, of potential projects to be worked on by your IT organization.
3. 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 architectures.
4. 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.
5. Staff allocation. Some people will potentially be hired, trained, and allocated to a project team before the project begins.
6. Process definition. We recommend Disciplined Agile Delivery (DAD).

2. The Enterprise Unified Process Inception Phase

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:

1. 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.
2. 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 you can.
3. 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.
4. 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.
5. Prepare the team 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.

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:

• 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 schedule estimates.
• 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 (Elaboration).
• Portfolio compliance. Does the scope of the project fit well into your organization’s overall project portfolio?

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.

3. The Enterprise Unified Process Construction Phase

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 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 acceptable.
• Cost and estimate acceptance. The current expenditures are acceptable and reasonable estimates have been made for future costs and schedules.
• 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 Transition phase. If the project fails in any area above, the project may be re-directed or cancelled.

4. The Enterprise Unified Process Transition Phase

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:

• 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 documentation.
• Support acceptance. The people responsible for support the system once it is in production are satisfied with the relevant procedures and documentation.
• Cost and estimate acceptance. The current expenditures are acceptable and reasonable estimates have been made for future costs.

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).

5. The Enterprise Unified Process Production Phase

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 Enterprise Unified Process defines a process to do that. The objectives of the Production phase are:

• 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.

The primary activities of the Production phase include:

• Operate the system; ensuring that it is available to end-users.
• Migrate the system to different hardware configurations and/or platforms.
• 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.

Most of these tasks occur in the Operations and Support discipline, a new discipline introduced by the Enterprise Unified Process. 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. TheProduction phase ends with the Release Replacement (RR) milestone. At this milestone, you must achieve the following:

• 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 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.

6. The Enterprise Unified Process Retirement Phase

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 reasons:

• 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.
• 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.

The objectives of the Retirement phase are:

• Complete the removal of the system.
• Ensure minimal interruption to users.
• Ensure minimal impact to business operations.

Activities of the retirement phase include:

• 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 database refactoring – because it will no longer be manipulated or required by the system being retired.
• 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.

The Retirement phase ends with the Release Retirement (RET) milestone. At this milestone, you must achieve the following:

• 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.

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.

8. Translations

• Japanese Translation