Production Phase: Enterprise Unified Process

The Rational Unified Process (RUP) project lifecycle ends with the Transition phase‘s Product Release (PR) milestone when the release of a system has been deployed to users. However, There is more to information technology (IT) than just building and deploying systems; they must be operated and supported after they are deployed. The Enterprise Unified Process^TM(EUP) extends the RUP to include a Production phase, as you can see in Figure 1.

Overview
Major activities
Release management
The release retirement milestone
Translations

1. Overview of the Production Phase

The goal of the Production phase is to keep systems useful and productive after they have been deployed to the user community. This process will differ from organization to organization and perhaps even from system to system, but the fundamental goal remains the same: keep the system running and help users to use it. Shrink-wrapped software, for example, will not require operational support but will typically require a help desk to assist users. Organizations that implement systems for internal use will usually require an operational staff to run and monitor systems. The Production phase, like the rest of the EUP, requires each organization to tailor it to meet their specific needs.

The Production phase ends when the release of a system has been slated for retirement or when support for that release has ended. The latter may occur immediately upon the release of a newer version, some time after the release of a newer version, or simply on a date that the business has decided to end support. The Release Retirement milestone, described in detail in a later section, is the final approval for a release to exit the production phase.

This phase typically has one iteration because it applies to the operational lifetime of a single release of your software. There may be multiple iterations, however, if you defined multiple levels of support that your software will have over time.

Figure 1. The EUP lifecycle: 2013.

Enterprise Unified Process (EUP) Lifecycle

2. Production Phase: Major Activities

Figure 2 depicts the workflow for the Production phase. Most of these tasks occur in the Operations and Support discipline. A brief description of the activities follows:

Operators monitor the system to make sure it is running properly, to start jobs and process as appropriate, to back up and restore data, and to generally look after the system and operating environment.
A support manager is responsible for managing the overall support efforts. The support manager prioritizes work, schedules and assigns tasks, ensures that support personnel have the resources to complete their tasks, and ensures that work is completed in a timely fashion.
Customer service representatives directly communicate with users and assist them in the use of the system. They provide advice and guidance to users and record enhancement requests and problem reports. They maintain contact with users who have reported problems and keep them informed of their progress.
System support representatives investigate problem reports and act on them. If they are caused by the system behaving improperly, they create defect reports that are then handled by support developers. If they are enhancement requests, they create enhancement requests that go to the Enterprise Change Control Board for consideration.
Support developers address critical defects (errors) in system behavior. They are responsible for making changes to the system to correct incorrect behavior. They are also responsible for packaging fixes to be applied and, if fixes are applied internally, for applying those fixes to deployed systems.
Preparations are made for recovery from a disaster such as a power outage of hardware or network error that disrupts processing. If a disaster occurs, the disaster recovery plan is executed.

Figure 2. The Production Phase workflow.

Production phase workflow

Other activities, in disciplines other than Operations and Support, that take place during Production include:

Requirements. During the Production phase, user enhancement requests are received. These new requests must be documented and analyzed.
Analysis and Design. Initial analysis of user enhancement requests takes place, as well as analysis and design required to resolving high-priority defects.
Test. Testing of fixes must be done before they are deployed. These may take the form of hot fixes (a code update to address a specific problem) or service packs (a collection of individual fixes). Regression tests that can be rerun when a fix has been made are crucial to the continuity of deployed software.
Configuration and Change Management. Change requests and defect reports will be accepted and managed during the Production phase. Configuration of the system needs to be tracked and updated as fixes are created and applied.
Project Management. Activities in the production are managed, just like any other activities. Operational activities are managed by an Operations Manager; support activities are managed by a Support Manager. They are responsible for assigning tasks and monitoring and reporting progress.
Environment. Support environments are modified as needed during the Production phase, as are operational monitoring tools, run-time environments, backup and recovery setups, etc.
Enterprise Administration. While systems are running, enterprise administrators maintain networks and hardware and also ensure that the underlying security and data infrastructure is stable. When necessary, they troubleshoot any problems that arise with capacity and upgrades, and they assist in testing and applying fixes.

3. Production Phase: Release Management

The Production phase for a release does not necessarily end when a new development project for a subsequent release of that product begins. You will have to operate and support earlier releases in parallel to development efforts. In fact, you may have multiple releases in production at the same time. For example, the operations and support for both versions 1.0 and 1.1 continues for a short period after version 1.1 is released. It is not until version 2.0 is released that support for version 1.0 is discontinued.

In reality, you will probably have multiple releases in development concurrently. It is not uncommon to begin the software development for release N+1 before release N has been completed and deployed. This may speed up the rate at which new releases are deployed and retired but will complicate your development efforts because you will have two teams updating the same code base. When you release a new version of a product, support for the older version(s) does not normally end immediately. When you release version 2.0 of your Whizbang product to the general public, for example, you will still support Whizbang v1.1 for a period of time (say eighteen months) and Whizbang 1.0 for a lesser period (say six more months). You will dedicate more resources to supporting v2.0 than the older versions, and you may even charge for support for the really old version, but you can’t cut off support for clients who haven’t upgraded until they’ve had a reasonable period of time to do so (or are willing to pay for continued support).

Supporting multiple versions of a system can become messy if it’s not managed properly. In most cases, subsequent releases of a product evolve from the work products of earlier release. Older versions often need to be supported and updated separately from the new release effort. This is often accomplished with a technique called “branch and merge,” which starts when the project team for the new release selects its development base for the new effort. You create a copy of all the relevant artifacts (use cases, design model, code, test cases, etc.) that they will work on. This is known as the “branch.” You base all their efforts on evolving their copy
of these artifacts to create the new release; for example, updating or adding use cases, evolving the design, or updating the code. The original artifacts are maintained separately. This needs to happen to allow the original release to be supported independently of the development effort.

Operations and support of the current version of the product must still happen while new development is progressing. If a critical error is found in production customers will want it fixed. The support team must be able to make and deploy fixes to the current version without impacting the development effort (and vice versa). For a period of time, there are two copies of the code base and other artifacts as the two efforts support different goals.

At some point, a “merge” takes place. When the development effort for the new release nears completion you must merge in the changes that the support team has done to incorporate as many fixes as possible. It may be done late during the Construction phase when new code is being written, or it may happen during the Transition phase. They do this by reviewing the changes that were made to the artifacts after the branch occurred and merging them into their base code. The old code base can be archived and removed if support for the older version is being discontinued,; otherwise both code bases must continue to be supported and evolved.

4. Production Phase: The Release Retirement Milestone

As you see in Figure 3 the Production phase ends with the Release Replacement (RR) milestone. The RR milestone determines whether the operations and support for a release of a system are to be ended. At this milestone, you must answers to the following questions:

Is the functionality provided by this release of the system no longer needed?
Are the stakeholders ready for the retirement of the release?

During this milestone review, the stakeholders determine if the functionality provided by the release of the system is no longer going to be provided. This may be due to any of several reasons: replacement by a later version of the system, replacement by another system, the business moving in a different direction, and so on. To pass this milestone, the stakeholders must agree that this functionality should be removed. Transition to the Retirement phase may be postponed if the project fails to pass the milestone review.

Figure 3. The phases and milestones of the EUP (click to enlarge).

5. Translations

Japanese