Upgrading software and hardware can be a complex process that needs careful planning, but by putting it off you could be missing out on valuable functionality and performance,
says Rob Jamieson.
Recently I have been visiting a lot of ISVs (Independent Software Vendors) for technical QBR (Quarterly Business Review) and events. Of course itÝs the ISVÝs job to sell new software updates and make you want them. This got me thinking about when these should be applied to your production pipeline.
2007 is going to be about change. There is change in the form of new hardware which has less focus on just increasing the clock speed of CPUs. This has led to diverting approaches by the ISVs to get the maximum out of their software for their customers. Hardware optimisation often falls in to second place because of the basic fact that most customers tend to want certain new features. Or they want a fix or tools to enable them to do something they couldnÝt do before in a shorter, and therefore cheaper, time frame.
" My wife was pushing me to get Sky+,
but I was worried that it would get filled up
with too many soaps! "
Different ISVs produce updates at different times of the year and over different periods. If the customer is a large corporation then they are likely to have a large design project on the go and updating software half way through is never a popular idea. Smaller companies often have a shorter design period so changing design software can become a simple process. This means that a few years after a design software package is initially launched the customer base is at different revisions or even platforms. In a lot of cases this becomes quite a large headache to manage for ISVs so they want to get everybody to the latest release even if itÝs just to reduce the number of support issues on different revisions.
We all know that one day we will have to update our software otherwise we would all still be using AutoCAD v2 on MSDOS. But the big question is when? Some customers believe that they should do it at the last possible moment. i.e. when they are forced to. This can be when the ISV will make you buy a whole new version of the software rather than allowing a version to be upgraded or it could be when itÝs not going to be supported any more. I always think that leaving it to the last minute is a bad approach because you could have missed out on using new features or functions which would have benefited your company earlier.
Soap dodging
An example of this for me is the Sky+ satellite box. I was happy recording TV onto SVHS if I wanted to watch something while I was out, whereas my wife was pushing me to get Sky+, but I was worried that it would get filled up with too many soaps! After having Sky+ for a few weeks I realised that I never needed to watch ýlive¯ TV again. I could automatically record it, start half way through and fast forward all the adverts. Yes, the Sky box was full of soaps but a retro fitted bigger hard disk, soon sorted that out. Now itÝs changed the way I watch TV and I will upgrade to Sky HD when the price drops (early adopters generally pay more) when more content is transmitted.
So if you are an early adopter you will likely have some issues in whatever you buy but there is a good chance this might give you a competitive advantage. A simple example of this is 64-bit versions of ISV software, which allow you to create models of a size that you could not even build before, let alone produce the drawings.
One thing that is often forgotten is the fact that if you are an early adopter you can be of real value to the provider of the software or hardware. If you give feedback to the provider they can make a better product. ItÝs just about impossible to QA every scenario, but by the very nature of workstations an update can then be provided and distributed. This is the reason a closed system such as software for aircraft instruments takes longer to develop. ItÝs hard to load SP1 at 30,000 ft for example.
Deployment strategy
So how would you deploy a new release of software? The first thing I do is use an offline server and workstation if possible. From your last backup load the server (always a good test to see if it works) then load the workstation with the current version mirroring your setup and apply the new version. Next, put a designer on the workstation for a day to see if it works as it should.
I understand that you might have licensing issues to resolve as well as the time to do it, but you can always ask your reseller or ISV to do it for you. This is all dependent on how confident you are that the update will work for you or how many changes have taken place in the software.
ItÝs my job to be up to date with what software can do and how itÝs implemented on hardware. I hate it when an installer fails or some basic function does not work when trying new technologies. If I look at what I had ten years ago the QA has come a long way. The complexity has greatly increased but we have also got so used to working out of the box today itÝs quite good to step back and see how much things have advanced. Remember Windows 95 anybody? At the time it was a great leap. If you try and use it today and compare it to XP or Vista you marvel at how you managed to get any work done. Yes, new technology forces change and naturally we resist it but there is also a sub culture to have the latest or the perceived best right now.
I like to be at the cutting edge just not the bleeding edge of technology. So IÝll just go and delete a few more soaps, IÝve told my wife itÝs the autodelete function but I donÝt think she believes me. Come on Sky launch a soap autodeleter function, pleaseÍ
Robert Jamieson works for the hardware manufacturer AMD. The opinions in the article are not necessary the opinions of AMD as a company.
