Managing Software Updates
|I'm just back from working with one of our YMCA's for a few days. We installed a software update while we were there, and it got me thinking. Books are written about managing software rollouts in organizations. But what about the minor update?|
Your vendor has fixed a few bugs, added a few features you and others have been asking for - now it's ready.
What planning and preparation is needed before installing?
To hear Tim O'Reilly talk, the direction the industry is moving in is to make the software update a non-event. In a now-famous piece, What is Web 2.0?, he claims that the new models have brought about the end of the software-release cycle, and goes on:
The open source dictum, "release early and release often" in fact has morphed into an even more radical position, "the perpetual beta", in which the product is developed in the open, with new features slipstreamed in on a monthly, weekly, or even daily basis. It's no accident that services such as Gmail, Google Maps, Flickr, del.icio.us, and the like may be expected to bear a Beta logo for years at a time.But your mission-critical systems are NOT Gmail or Flickr. Sudden and unexpected changes in software behavior are not just little treats for your staff, but issues that require policy consideration and training. They can change your workflow. They can expose you to risk. And a day long unexpected outage, like Google's Blogger outage the other day, can be a real problem if it occurs at the wrong time.
A real-life example.
The changes that we've been making for enhanced credit card security basically narrow the window during which a full credit card number is retained by the system. This has an impact on issuing a credit card refund. During the walkthru of the new credit card features for this YMCA, the team realized staff members now need to ask for the card number again when a member requests a refund. Other minor policy issues came up as well during our walkthru - and these changes needed to get out to the full staff before the new features could be installed.
Besides these usage issues, there is risk to consider. There is always a risk of some new problem when changing your software. The more enhancements and fixes in the release, the higher the risk. The more setup and interfacing with other players and systems, the higher the risk. In this example, the big risk is obvious: what if we get the new software set up wrong and it is not communicating with the bank? The users could be out cash!
So even for routine maintenance updates in your mission-critical systems, I'd stop, take a breath, pull your technology committee together, and consider the following:
Tags: nptech, implementation, tech_planning