Updating software and systems should be easy and straightforward. It is neither.
I recall when technology used to last a bit longer than it does today. Even if a new and improved product or technology was introduced, replacements were typically available for years and sometimes a third party provided equivalent replacement parts. However, computer-centric hardware and software technology has changed all that.
My mailbox is constantly getting End of Life (EOL) notices or no longer will be supported notifications. It’s sort of an ultimatum – Upgrade NOW or else. Adding insult to annoyance, as software products want to move to the cloud we no longer buy anything, it’s all subscription based fees, essentially we rent forever. Even some products have the requirement for the application be downloaded for offline use, it has a heartbeat that still needs to go online to validate the subscription regularly [don’t worry it will auto sync next time you connect].
What if you want to change products, WELL, if it syncs locally then you will first need to download everything, delete all content and data, and then upload to the new services and possibly convert all your content or data based on what the new service supports. If your stuff is all video and potentially hi-rez, then you will most likely incur pretty hefty fees for the download.
Recently I received one of these EOL notices for a perfectly working hardware product that doesn’t need any firmware updates – so far. Along with the notice I’m told that expansion components will no longer be available. An internet search shows there are no third party replacements. What are the options?
Admit it, you would like to just say no to software updates.
Previously I discussed one of the challenges that can develop when two companies merge, or one buys out the second is the loss of product support. Suppose a vendor integrates a third-party component product in their overall system, but then acquires a competitor of that third-party product?
Now, in order to not compete against itself, the company stops supporting the initial third-party product only to develop technology for their newer products. While their product gets updated, the original third-party solution quickly becomes generations behind and now running an obsolete and unsupported version. The device may no longer operate correctly or even become incompatible.
Version Management Strategy
Version management applies more to software and firmware. However there is certainly hardware versioning that needs attention. Consider the hard drives or tape drives being used in a digital tape library or SAN. The original versions may no longer be available. Version Management is a little more complicated than just keeping a list of hardware, software and firmware. The process includes paying attention to updates and having a schedule for checking and installing updates.
I am suggesting that version management requires a strategy. All updates are not created equal. Some updates fix bugs or issues. Other updates may add features or, based on the existing version, it may not be necessary to update.Updates to the operating system needs to be managed as well.
On a recent project, we were relocating a device that communicates to several applications. Each of the vendors thought this would be a good time to update their software and firmware. Several potential concerns about the multiple vendors’ plans were quickly identified.
- The companies didn’t coordinate with each other.
- They didn’t test the impact on the other applications.
- Each vendor wanted a 4 hour window of down time.
- None of the updates either fixed a problem or added a necessary feature.
I coordinated a call with all the vendors and client. Were any of the updates critical? No was the answer. Would not doing the updates interfere with the current primary task? No was the answer. I suggested that given the number of moving parts in the main task, that we not update anything and plan on saving the changes for a future date. Plan being the operative word, because there is a sequence to updates or things break.
Even the main task requires different applications to be either disabled or shutdown so they don’t get errors. Then there is the startup sequence to make sure all communications are re-established.
The first part of the strategy is to capture the running version of every piece of hardware, software, middleware, firmware and very important include OS (operating system) versions.
Many vendors are inconsistent with their updates or even announcing them. The next item is adding the url or location to check for updates. Are the updates included in an SLA or are their costs? Who is responsible to install the update the owner or the vendor?
And now for the trick question!
What other applications, devices or systems are impacted by the update? This is called dependencies. In the above example, Vendor A was going to perform a courtesy update while doing a different task. Vendor B is the controlling technology for Vendor A’s product. Vendor A didn’t check with Vendor B and when Vendor B was informed of the update they determined that the proposed update by Vendor A was incompatible with the Vendor B software. The solution was for the client to update the Vendor B product first.
In another instance, a production device was updated to address a performance issue. However the vendor forgot to first determine the exact configuration with the result that the firmware in an attached black box device was not compatible with the update. The engineers spent a lot of time figuring out why everything stopped working. The black box guy was not aware that the drivers in his product were no longer supported in the new version. The solution required bit of scrambling to build compatible firmware that no one knew would be needed.
Understand the Dependencies
How often should you update? What’s the difference between and update and upgrade? Relying on Windows Auto Update is a NO-NO and Microsoft’s Update Tuesdays is not mandatory. Typically applications are tuned to a specific OS version and configuration. But OS updates can break things. Security is everyone’s concern and requires a larger discussion in a separate article. For the purposes of this discussion security updates and patches should be part of version control and needed to be managed.
If it’s at all possible, get the update schedule from the vendors or at least frequency of updates. Build a regular schedule to check for updates, annually, bi-annually or quarterly as part of a routine maintenance program.
Version changes can be disruptive. Ask yourself these questions.
- Does the system need to be offline for the updates to be installed?
- Are configurations safe?
- Are the configurations compatible with the new version of the system?
- When the changes are complete, can they be backed up?
In today’s computer centric world, having a version management and control strategy is imperative. Engineers must be able to identify the dependencies that exist between systems, where they touch and how they are integrated. Armed with this information, they will be in a better position to predict what may happen when performing an update or version change to one system and how those changes may ripple down to other systems.
Related Editorial Content
Broadcasters have historically not had to endure regular large-scale technology transitions. Sure, the industry moved from B/W to color, analog to digital, and SD to HD. But the upcoming move from the familiar and comfortable SDI technology to an…
Troubleshooting IP-centric technologies can be a new and challenging undertaking for engineers. Often it becomes a case of "You don't know--what you don't know," until it is too late. Consultant Gary Olson describes his experience in helping staffs troubleshoot new…
Broadcasters now find themselves on one side of a digital gap. On one side we have SDI, the other side IP. Engineers want to reach the far shore, but do so without sacrificing their investment in current SDI solutions. This…