Both RUP and ITUP have well-defined approaches to managing changes. 

• In RUP, changes involve existing applications or systems and the process is called Change Request Management within the Change and Configuration Management Discipline. 
• In ITUP, changes involve the entire IT infrastructure and the process is called the Change Management process.  This is essentially the same as ITIL® Change Management. 

Commonality

The high-level lifecycle of managing changes is the same within both RUP and ITUP.  The lifecycle includes:

1. Submission of a proposed change
2. Assessment of the proposed change
3. Approval or rejection of the proposed change
4. Implementation of the approved change
5. Verification that the change was implemented

At a high level, both RUP and ITUP process changes in the same way.  However, the context in which changes are made and the low-level approach to processing changes is different in ITUP and RUP. 

Variability

The Change Request Management process in RUP involves the capture and management of changes requested to a system under development.  Change requests may be initiated by anyone to propose a change to either an existing system or a new system.  Change requests are managed by the development project and are tracked as they are assessed, approved, implemented. 

ITUP’s Change Management process handles all requested changes to the IT infrastructure.  This may include new or existing systems, but may also include changes to the operation of applications and services, operational procedures, service requests, and anything else that someone might want to see changed within the IT infrastructure.  A requested change comes in the form of a Change Request. All Change Requests are managed by the Change Advisory (or Approval) Board.  Typically, Change Requests that request changes for existing systems are forwarded to the appropriate development organization, although such changes that may affect other systems may first be considered by the Change Advisory Board. 

Thus, changes have a different context in RUP and ITUP.  RUP focuses specifically on an existing application, whereas ITUP focuses on all IT changes, including changes to existing applications.

Examples of situations in which RUP Change Request Management would be integrated  with ITUP Change Management include:

• Making a change to an existing application
• Creating a new application

These are described in the following sections.   

Making a change to an existing application

An IT user requests a change to an existing IT application.  This flow of events is shown in Figure 1.

• A Change Request in ITUP is sent to the ITUP Change Management process. 
• RUP Change Management is involved at this point, since the application stakeholders want to provide their own assessment of the requested change. RUP Change Management creates a Change Request based on the Change Request.  (It should be noted that another change must be made to the Service Catalog, part of Service Level Management, because of the new functionality.)
• The approval of the RUP Change Request Management process (along with those of other assessment groups) are provided to the Change Advisory Board of ITUP Change Management. 
• The Change Advisory Board approves the change as worthy of implementation. 
• The Change Request is sent to the Portfolio Management process to determine how the development project would fit within the portfolio of existing and anticipated projects and when resources would be available for the project. 
• Portfolio Management eventually approves the initiation of the update project and creates  a project charter, which is sent to the development team for that application.  This project charter is used to generate one or more Change Requests for that application.   
• The development team implements the change, verifies the change in the build, and tells the ITUP Change Manager that the updated application is ready for deployment.
• The Change Manager makes sure the Service Catalog has also been updated, then the application is deployed out via Release Management.
• The results of deployment are reviewed by the Change Manager and the Change Request is finally closed. 

Figure 1 -  Application Update Sequence of Events

Creating a New Application

The Service Level Manager submits an Change Request requesting a new application, which represents a new IT service.  This flow of events is shown in Figure 2. 

• A Change Request in ITUP is sent to the ITUP Change Management process. 
• The Change Advisory Board asks various teams to assess the impact of the proposed application.  This involves a variety of teams who consider availability, capacity, security, and other aspects. 
• These assessments are reviewed as part of the approval of the application. 
• The Change Advisory Board approves the change as worthy of implementation. 
• The Change Request is sent to the Portfolio Management process to determine how the development project would fit within the portfolio of existing and anticipated projects and when resources would be available for the project. 
• Portfolio Management eventually approves the initiation of the update project and creates  a project charter, which is sent to the development team for that application.  This project charter is used to generate one or more Change Requests for that application.   
• The development team implements the change, verifies the change in the build, and tells the ITUP Change Manager that the updated application is ready for deployment.
• The Change Manager makes sure the Service Catalog has also been updated, then the application is deployed out via Release Management.
• The results of deployment are reviewed by the Change Manager and the Change Request is finally closed. 

Figure 2 -  Creating a new application

Mapping Between RUP and ITUP

RUP Change Request Management and ITUP Change Management map in the following way.

Summary

ITUP Change Management and RUP Change Request Management are similar at a high level, but show important differences when placed within their respective contexts.