Effective Software Deployment

Deploying software is a complex endeavor, one that you should plan for early in the development life cycle.

If you can’t get software into your users’ hands, then what is its value? Absolutely nothing. Software deployment is a complex endeavor, all too frequently ignored in favor of sexier topics such as distributed object development, components, or the latest version of the Java development kit. I’ve learned about successful software deployment from developing and releasing mission-critical, object-oriented software in a variety of environments.

Figure 1 depicts my extended life cycle for the Unified Process (see “Thinking Objectively,” Oct. 1999). I’ve extended the Deployment workflow to begin in the Inception phase, as opposed to the Construction phase in the initial version of the Unified Process (The Rational Unified Process by Phillipe Krutchen, Addison Wesley Longman, 1999). Because deployment can be quite complex, especially when your user base is physically dispersed or you have a wide range of system configurations, you must start planning early in your project life cycle.

Figure 1. Extended Life Cycle for the Unified Process

To meet the real-world demands for deploying mission-critical software, apply the “release stage” process pattern shown in Figure 2 (reprinted from my More Process Patterns, Cambridge University Press, 1999). When deploying a system, consider three basic tasks: preparing for release, releasing the application to operations and support, and releasing the application to your user community. Let’s map these tasks to the Deployment workflow on a phase-by-phase basis.

Figure 2. "Release Stage" Process Pattern

Inception Phase

You tackle key management documents—your initial risk assessment, estimate, and plan—during the Inception phase. The Deployment workflow focuses on your system’s initial release planning, including identifying your deployment audience’s potential release window, and general deployment strategy—will you release the software all at once or incrementally?

Understanding your deployment audience is critically important to your project. There are at least three distinct groups to consider: your users, your operations staff, and your support staff. You must also determine the level of control that each group has over deployment. For example, both operations and support departments often have defined criteria for the release of new software. Further, I once worked for an organization where all software had to be first accepted by union representatives before it could be deployed. Identify early in your project the deployment hoops that you’ll have to jump through.

Elaboration Phase

The Elaboration phase focuses on detailed analysis of the problem domain and defining an architectural foundation for your project. When you define architecture, you must define the deployment configurations for your system—each individual deployment configuration should be documented with a UML deployment model that shows how you’ll organize actual software and hardware components. Deployment modeling is arguably part of the Analysis and Design workflow, but it should be part of the Deployment workflow because it is a key deployment artifact.

Data conversion is key to deploying a new software system. It’s a complex effort that should start early in the software life cycle, typically during the Elaboration phase. You must analyze your legacy data, which entails identifying the legacy data sources, using a persistence model to model the legacy schemas, and choosing official sources for each data attribute that is stored in several places. You must understand your existing legacy data schema so that you can convert it to your new schema, which will be finalized as part of your Analysis and Design workflow efforts during the Construction phase.

During elaboration your deployment plan will evolve, likely based on one of several common installation approaches. Perhaps someone will visit every user and install the software by hand or perhaps the software will be physically distributed for users to install on their own. You might decide to have users log on to a specific location, such as a web site or internal server, to download and install it from there. Perhaps your software will automatically install itself when a user logs in one day, a possible built-in feature of your organization’s technical infrastructure. Regardless of your general installation strategy, you’ve got some planning to do.

Construction Phase

During the Construction phase, you develop detailed design and source code for your application. The majority of your Deployment workflow efforts during this phase will focus on legacy data conversion modeling and planning, including the development of scripts and tests to perform the actual conversion. A related effort is legacy equipment conversion; you might need to upgrade user desktops or internal application servers to run your new system. The earlier you perform equipment conversion the smoother your eventual deployment will actually go. Attempting to upgrade hardware and software simultaneously can be very difficult, so separate these two efforts if possible.

Another important effort is developing operations, support, and user documentation, the potential artifacts of which are summarized in Table 1. You will probably need one or more technical writers on your team to develop this documentation. In parallel with writing the documentation, your team must assemble the installation package, which includes procedures and documentation.

Deployment planning continues during the Construction phase. You’ll probably need to negotiate your deployment plan with the operations and support departments, as well as with other projects that are also planning on deploying software, to ensure that your project fits into your overall corporate deployment system. An important feature of a good deployment plan is that it includes go/no-go decision points during the actual installation. If at defined times during the installation you have not reached a certain point in the overall installation process, you can roll back your efforts and try to install again at a future date. This is a critical concept for projects that have very stringent deployment requirements, such as software to replace existing mission-critical systems. As Figure 2 indicates, your release plan should be accepted towards the end of the Construction phase or early in the Transition phase.

Transition Phase

The purpose of the Transition phase is to deliver the system to your user community, making the Deployment workflow a key focus of this phase. As shown in Figure 2, you must finalize and accept the user, support, and operations documentation before deploying the system. Packaging is also important, although in the case of the Unified Process this is an effort that is split between the configuration and change management and the Implementation workflows. To finalize your software packaging, you’ll define its deployment baseline, a configuration management activity, and to perform a “final” build for the software, an Implementation workflow task.

Spreading the Word

Training and education are often key to your deployment success. If the learning curve is too steep, users will quickly abandon it. Further, your operations staff needs to understand how to keep the new technology running properly. Announce the anticipated deployment schedule, including the expected training and installation dates, and train your operations, support, and user communities appropriately during the Transition phase.

During the Transition phase, and perhaps even during the Construction phase, hold regular release meetings with the key players involved in the actual deployment. Discuss testing with quality assurance staff, implementation with developers, and current production with operations staff. Be sure to meet with support and user representatives, so they can inform you of their issues.

Actual deployment occurs toward the end of the Transition phase. At this point, you perform any required data conversion or run the new system in parallel with the existing system for several weeks to ensure that it actually works in production. You may also choose to send a pilot release to a subset of your user community verifying that it runs before you “inflict” the system on everyone. Do the same for the support department so they can simulate production problems when users contact them for help. Finally, as Figure 2 indicates, you may also need to deploy a corresponding support process for your system. Regardless of how you go about it, you should plan these efforts first.

As shown in Figure 1, the Deployment workflow does not explicitly extend into the Production phase of the enhanced life cycle for the Unified Process. Note, however, that because your user community is constantly changing—people are transferred, hired, and move on to other organizations—the Operations and Support workflow must include installation and deinstallation of your system once it is in production.

Successfully releasing software requires analysis, planning, and implementation. Deployment efforts occur almost from the very start of development and continue through the four Development phases of the enhanced Unified Process life cycle. You must consider the needs of, and work closely with, three distinct groups: users, operations staff, and support staff. Why is the Deployment workflow important? The answer is simple: you may be able to create the greatest software in the world, but if you can’t deploy it, it really doesn’t matter.