Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Planning for Deployment
It isn't enough to build software—you must also deploy it, so you can operate and support it effectively once it's in production. When you're developing complex software (the kind of systems typically tackled with component-based technologies such as J2EE or .NET), your deployment efforts can be similarly complex. Therefore, whether you're building a replacement system or plowing a fresh "greenfield" development, adequate planning is essential for successful deployment.

Step by Step
First, you must identify your system's customers. The business side includes direct users of the system, along with indirect users such as managers who receive reports based on data generated by your system. With respect to deployment, your primary technical customers are the operations and support staff, two groups who clearly need to be involved with deployment planning efforts. Once you know who your customers are, you can identify what they need from the system and related artifacts, discover their potential roles in the overall deployment effort, and negotiate their actual involvement.

The next major issue is developing your deployment strategy: Will you run the new system in parallel with the existing one or perform a cutover? Running the systems alongside each other lets you easily back out to the original system if the new one runs into problems. However, parallel operations require significant effort on the part of everyone involved: Your users will need to do double entry, the operations staff must run both systems, the support staff will have two systems to support, and the development staff may need to create integration code that temporarily works behind the scenes to synchronize data. For many systems, particularly those supporting online customers via the Internet, a cutover is the only option—few customers would be willing to place their book order with both Amazon version N and Amazon version N+1. With a straight cutover, you'll need to plan for the downtime when the cutover occurs—a period that could last from a few seconds to a few hours or even a few days, depending on the system being deployed. The ability to back out becomes critical with this approach, requiring additional resources to develop and test "de-installation scripts." In fact, many system deployment efforts fail miserably because the development team didn't consider how to back out of their new system, only to discover that they had to do so because of an unforeseen problem during installation. An effective installation routine will include go and no-go checkpoints at which you determine whether deployment efforts are on time and working smoothly. If you don't have these crucial checkpoints, you need to consider stopping and de-installing to a known and safe state from which to attempt deployment at a later date. Never assume that your deployment efforts will go smoothly.

From Back to Front
Working backward is an effective technique for deployment planning. Envision the system in production—users working with it, operations professionals keeping it going, support staff helping users to work with it, and developers modifying it to address defects and implement new requirements—and ask what has to happen to get the system to that point. Then compare that vision with the current environment to determine what you must do to successfully install your system. In my experience, forward planning generally isn't sufficient for system deployment, because the requirements often don't reflect issues pertinent to your system's production phase—that is, the need to operate and support your software is often assumed and therefore not explicitly reflected in your requirements. This problem can be exacerbated when your project life cycle doesn't explicitly include a production phase or even an operations and support workflow. What is out of sight is often out of mind.

Start deployment planning early in the project life cycle, particularly when deployment may be a complex issue. For example, I was once involved with a project for which we needed to physically install a system at 450 separate locations. Our users were geographically dispersed and computer illiterate. Depending on the location, we had to either replace existing hardware or install new equipment. At each location we needed to run a data backup and conversion program, and we had to deploy the system at night so as not to disturb the day-to-day operation of the business. For another project, we had to deploy our systems into a dynamic environment in which several systems worked together, shared common components, supported 24/7 operations and had very limited deployment windows due to service level agreements. As you can see, deployment can be very complex—it may be the most difficult issue that your team faces. Accordingly, it should be considered early, because if you can't deploy your system, you shouldn't build it.

An early focus on deployment not only enables you to avoid problems, it also lets you take advantage of your experiences during development. For example, take notes on what works and what doesn't when you're deploying software into your staging area (Thinking Objectively, May 2001); these notes can serve as the backbone of your installation scripts. For example, when deploying an Enterprise JavaBean (EJB) application for the first time, you'll encounter several common "gotchas," such as how to define XML deployment descriptors, where to put them and how to deploy EJB JAR files.

During development, you'll also discover dependencies between your system and others—dependencies that should appear on your deployment model, but affect your deployment plan because they imply the order in which updates to the various systems must be installed. You'll need to negotiate deployment efforts with the other teams that own the systems that your system depends on, effectively creating a cross-project effort that would be included as part of your Infrastructure Management workflow efforts (assuming that you're following the enhanced life cycle of the Unified Process). If your system's interface changes, or if you need new ways to access their systems, they may also need to release all or part of their systems before yours.

Training your project customers is always an important part of deployment. They may even need training beyond how to work with your application. For example, this might be the first time that some users are working with a PC, a browser or even a mouse. Similarly, this may be the first time that your operations staff works with a new technology that your system uses, such as an EJB application server, and therefore they'll need to be trained in that technology to be qualified to work with your system.

Pump It Up
When building a new system, you often discover that the existing environment isn't sufficient to support it; therefore, any deployment efforts must include activities to perform required upgrades. These upgrades could include changes to hardware, operating systems, databases or middleware. If you don't know the current status of your technical environment, you'll also need to plan for activities to perform the required legacy analysis. If you're upgrading your database, you may be upgrading the software itself or the database's schema; consequently, you'll need to include data conversion activities in your deployment plan. Physical considerations should also be considered when performing environment upgrades. Is sufficient power available? Are working areas in place? Is there sufficient space in the building(s) that you're deploying to? Are there enough network drops to accommodate new workstations?

You may also need to plan for upgrades to your support environment. Are your existing change management process and required tools in place and sufficient for your needs? If not, you need to plan for appropriate development, training and installation of said tools and procedures. Your support department may need to have their support problem simulation environment or help desk product (which they use to track defects and enhancement requests) upgraded, as well.

A good reality check for your deployment plan is your deployment model; in fact, I often develop the two in parallel. Different deployment architectures, as described by your deployment model, will require different strategies for installation, and therefore will demand different plans. For example, a fat client system requires an installation script that can be operated by your users, whereas an n-tier thin-client application requires an installation script that can be followed by your operations folks: Different customers for the installation script require different levels of script sophistication, and of the strategies used to develop and test those scripts.

Don't forget to distribute the documentation for your system, particularly user documentation (Thinking Objectively, June 2001). Electronic documentation can be deployed along with your software, but physical documentation will need to be distributed appropriately. Will physical documents be distributed as part of training sessions, on demand via some sort of document order process, or as part of the system installation itself (in the box for shrink-wrapped software or distributed via your mail system for internally developed software)? Thinking these issues through in advance will save you headaches later.

Now Presenting …
A small but critical part of deployment is the release announcement, a task that may require significant preparation. Your announcement could be an e-mail to your customers, a press release, or even advertisements on television, in magazines, or on the Internet. Release announcements are important because people want to know how and when the new system will affect them, if at all. Remember, you're disrupting their lives, and your deployment efforts should respect this fact.

Deployment planning is an iterative task, one that starts early in the project life cycle and continues until the actual deployment of your system. Most projects don't need a separate deployment plan, but the fact remains that deployment activities must be planned, regardless of the nature of your project. Never underestimate the complexity of software deployment.

RELATED ARTICLES No Related Articles		TOP 5 ARTICLES No Top Articles.