Finding the cause helps solve future application deployment issues
Application deployment issues put a black mark on successful enterprise applications. Learn to guard your applications from the most common pitfalls.
Whether you are rolling out an entirely new application or simply upgrading an existing program, you probably experience a moment of trepidation when you push the go-live button. You might even feel an overwhelming sense of impending doom at that moment if your last deployment effort blew up in your face. You remember all too well what it felt like to see the IT helpdesk buried under a pile of tickets that started streaming in just minutes or hours after an update went live.
Your organization isn't the first to make a misstep resulting in a deployment nightmare. Understanding the root causes of application deployment issues is the first step toward avoiding future deployment detonations. Here are a few of the most common mistakes.
Disconnect between IT and end users
Clear communication prior to deployment is imperative. If IT does not distribute information about the purpose and parameters of the deployment, users may concoct their own story about what's going to change. Then, you see IT flooded with questions like, "I thought this release was going to fix my pet peeve XYZ that I complained about last month. What happened?"
Even a flawless deployment can look like a failure if it doesn't meet the user's needs. The goals of IT may be entirely different from those of the final customer. For example, IT may be under a lot of pressure to meet a certain deadline for deployment. Hitting that launch date might take precedence over ensuring the UI is easy to use. That's a recipe for complaints and a good way to ensure even more resistance to adopting new technology in the future.
IT will never experience a smooth deployment if 50% of the users can't figure out how to use the new features. Pre-deployment communication must also include training if any aspect of the new technology is not self-explanatory and intuitive (in the experience of the average end user). IT can save a lot of help desk requests by ensuring appropriate documentation is developed and provided to users at the time of deployment.
Missing files or scripts
With software, all it takes is one little JavaScript file that didn't get collected and deployed with the rest to start an avalanche of error reports and broken functions. If this is a recurring problem due to human error during manual collection and packaging of the files, it is high time to seek out an automated solution. In addition to making sure all scripts are present and accounted for in the application itself, you should also ensure that the installation program is double checked and fully tested.
Inadequate testing environment
Until you put everything together and run it for real, there's no telling where the blind spots will be in a program. Sometimes, a factor as simple as the access settings on an end user's content delivery network can stymie your deployment. The application might work fine in the U.S. but be completely unusable (or have an unacceptably long load time) at satellite offices in other countries. An application that works fine with the most commonly used browser might have serious performance issues in your organization's second most popular browser. If you can't find and fix these problems in the testing environment, you'll have to deal with a flood of HTTP 401 requests.
Sometimes, the inadequate testing environment isn't even in your own organization. This may be the case if you are building a program with modules that were downloaded from who-knows-where to use in your application. They may have a good track record for the original designer who tested them with a small load, but they can break when they scale up to an enterprise-level deployment. Ensuring your testing environment is as close a match as possible to the "real world" and that the load is sized appropriately are essential precautions for side-stepping these pitfalls.
Doing too much at once
Legacy equipment, data and software can all cause application deployment issues. You may not be able to push through a concurrent upgrade of all the systems your application touches. In fact, that might actually create a project so complex that it will simply never get finished. In that case, consider a limited deployment that runs in parallel with the existing application.
Sometimes, it is the deployment method itself that is incompatible with outdated systems. For example, you might rely on remote access to distribute or install software across a broadly distributed network. If a local computer doesn't have Secure Shell (SSH) installed, you may run into problems. Here, too, a section-by-section deployment based on geographic location, department or other parameters gives you a chance to troubleshoot without every user breathing down your neck at once.
Controlled deployment may seem like more work up front (especially if you have to create more code that permits use of both the old and new versions). However, easing into a deployment rather than jumping in with both feet can prevent some pretty ugly crashes.
