Home | About | Recent Issue | Archives | Events | Jobs | Subscribe | ContactBookmark The Sterling Report


Will the enterprise market spend significant IT budget on Windows Vista in 2007?



Extending the Rational Unified Process: RUP to EUP

By Scott W. Ambler, Senior Consultant, Ronin International, Inc.

Material for this article has been modified from The Enterprise Unified Process: Extending the Rational Unified Process by Scott W. Ambler, John Nalbone, and Michael Vizdos to be published January 2005 by Prentice Hall PTR.

Many information technology (IT) departments struggle to fulfill their primary mission - to deliver, operate, and support systems that enable the organization to meet its business goals. Business stakeholders want new systems that meet their actual needs delivered on time and on budget. They want to pay for functionality once and then reuse it again whenever appropriate, and they want their systems to work together effectively. Business stakeholders also want their systems to be properly operated and supported - they neither can afford to have systems become unavailable, nor can they expect to not receive help when it's required.

It is crucial for an IT organization to follow one or more software process, and many organizations have chosen to adopt IBM's Rational Unified Process (RUP) (IBM 2004, Kruchten 2004), the lifecycle for which is depicted in Figure 1. The RUP development process helps to guide project teams in a consistent, affordable, and (relatively) predictable approach, which results in high-quality systems that meet the needs of stakeholders.

Figure 1. The RUP v2003 system lifecycle.

The RUP is structured in two dimensions: phases, which represent the four major stages that a development project goes through over time, and disciplines, which represent the logical activities that take place throughout the project. The serial aspect of the RUP is captured in its phases and its iterative nature of the RUP in its disciplines. The underlying assumption of this article is that your organization has adopted the RUP and is relatively successful with it. However, you're now ready to take the next step, which is to extend the RUP to address all of your IT process needs.

1. Beyond Software Development
There is more to the lifecycle of a system than software development, as you can see in Figure 2. The operation and support of a system after it is in production is critical to your success; why bother building the system if you can't run it? The retirement of a system that is no longer needed or that is to be replaced by another system is also important. Both production and retirement efforts require different skill sets and activities from the system development. Therefore, you need to go beyond the RUP.

Figure 2. The complete system lifecycle.

It doesn't end here - most organizations deal with more than one system at a time, so they need a full IT process that reflects this reality. Cross-system enterprise issues such as portfolio management, enterprise architecture, enterprise administration, and strategic reuse are critical to your IT success. The danger of enterprise activities is that it is possible (and unfortunately common) for project momentum to grind to a halt when inefficient or unrealistic enterprise processes are thrust upon individual project teams. Enterprise groups must recognize that they exist not only to protect the enterprise but also to actively enhance system development efforts as well. They must support development teams, not hinder them.

You need to extend the RUP with the Enterprise Unified Process (EUP), first introduced in 1999 (Ambler 1999). Both the EUP and RUP are instantiations of the Unified Process (UP) (Jacobson, Booch, and Rumbaugh 1999). The UP, also known as the Unified Method or the Unified Software Development Process (USDP), was originally a framework from which system processes were to be instantiated.

The EUP lifecycle diagram is depicted in Figure 3. The EUP adds the operation and support of a system after it is in production and its eventual retirement to the RUP. Furthermore, the EUP adds seven new enterprise management disciplines. The RUP is a great start that the EUP builds upon.

Figure 3. The EUP v2004 IT lifecycle.

2. EUP Phases
Let's start by examining the serial aspects of the EUP captured in its phases. The EUP encompasses six phases - Inception, Elaboration, Construction, Transition, Production, and Retirement. Each phase ends with a well-defined milestone. At these points, the stakeholders assess the project, including what has been done and the plans for moving forward. A go/no-go decision is made about whether to proceed with the project. Each phase has a specific set of goals, which are addressed within the iterations of the phase, so that the phase milestone can be met. Figure 4 shows the primary activities and milestones of each phase.

Figure 4. The phases of the EUP.

  • Define project scope
  • Estimate cost and schedule
  • Define risks
  • Develop business case
  • Prepare project environment

Lifecycle Objectives (LCO)
  • Scope concurrence
  • Initial requirements definition
  • Plan concurrence
  • Risk acceptance
  • Process acceptance
  • Business case
  • Project plan
  • Specify requirements in greater detail
  • Identify architecture
  • Validate architecture
  • Evolve project environment
  • Staff project team

Lifecycle Architecture (LCA)
  • Vision stability
  • Requirements stability
  • Architecture stability
  • Risk acceptance
  • Cost and estimate acceptance
  • Realistic chance to succeed
  • Project plan
  • Model, build, and test system
  • Develop supporting documentation

Initial Operating Capacity (IOC)
  • System stability
  • Requirements stability
  • Prepared stakeholders
  • Risk acceptance
  • Cost and estimate acceptance
  • Project plan
  • System testing
  • User testing
  • System rework
  • System deployment

Product Release (PR)
  • Business acceptance
  • Operations acceptance
  • Support acceptance
  • Cost and estimate acceptance
  • Operate systems
  • Support systems
  • Manage change requests
  • Monitor systems
  • Prepare for and recover from disasters

Release Replacement (PR)
  • Release removed or system scheduled for removal
  • Skateholder acceptance
  • Operations acceptance
  • S
  • upport acceptance
  • Detailed integration analysis
  • Rework of connected systems
  • Data migration
  • System integration test
  • Removal of system

Release Retirement (RET)
  • System removal
  • Skateholder acceptance


  Home | About | Recent Issue | Archives | Events | Jobs | Subscribe | Contact | Terms of Agreement
2006 The Sterling Report. All rights reserved.