Online Payment
image description

tech blogging > our corner of the web

tech blogging >

IT Obstacles :: When Should You Update Your Systems?

Tuesday, May 16, 2017
By Andrew Smith, Director of Technical Services

How many aspects of your life fall into the category of “If it ain’t broke, don’t fix it”? In technology, this can be detrimental to our business and personal lives if we don't pay close attention to the risks associated with taking such a stance. Attempting to utilize outdated technology can be a money saver on the surface, but more often, it's a money trap waiting happen.

Years ago, I was working on a series of systems, determining use and necessary upgrades for each. I came across several old ones that were in use and identified one, an AS400 that was over 15 years old. The system was critical to about 400 individuals, and each person that I talked with promptly told me two things: They could not work without the system, and it was ok because they paid support for that system. These folks were adamant that we could not touch that system because “It was special”, “It could not be down”, and “They had support so we didn't need to worry about it.”

As my team reviewed the AS400, I sat down with the system owner and we called the vendor. They had been paying an excessive amount of money each year for support and I asked the vendor a simple question. “If the system goes down with a hardware failure, will you guarantee it will be repaired?” There was a pause, and then the answer came back. “Our SLA is, we will have a technician on site within 4 hours.” I smiled, waited, and asked the question differently, “Can you guarantee you will be able to bring the system back online”, and the answer came back again, “Our SLA is, we will have a technician on site within 4 hours.” We had some additional discussions but after the call I looked at the system owner, a non-technical person in charge of a major area, and asked if they understood what had just happened. They were very thoughtful and simply said, “I think we need to look at some additional options.”

We replaced that system with a newer box and worked towards the replacement of the software. By utilizing virtual techniques we moved the system to a more resilient platform, ensuring it would be online as necessary, and that the solution would not be a tech onsite within 4 hours, but instead, a system supporting 400 workers that would be online even in the event of a disaster.

So why was this a good decision? It's easy. First, if the entity had gone down for even one hour, the 400 workers affected would cost an excessive dollar amount.. Even if these were jobs at $10 an hour, which they were not, that's $4000 an hour. Second, if the data had been lost, there wouldn't have been alternate operating systems or hardware to bring the system back online and the cost of losing the data could be immeasurable. Third, the system itself, being out of date for so long, had numerous security issues and could easily have been compromised. This alone can destroy both the credibility of a business and finances with minimal opportunity for recovery. Fourth, the system itself was impacting users and becoming less usable, causing employees to find a workaround to do their job - costing the company even more money. 

So how does this matter to small and large businesses alike? Well, as the age of a system goes up, we add risk and potential points of failure, including replacement issues. The bigger the system with more moving parts, the more likely it is to run into issues.

A simple approach can be:
Hardware Age + Operating System Age + Risk + User Impact + Financial Impact - Disaster Recovery Resilience < 10

As hardware ages it requires updates and possibly replacement parts. As the parts become less available, the risk to the system increases. If you virtualize you should consider the virtual strategy to be part of the same equation, but in the case of the system, your hardware age is always 1 as the virtual system then becomes the necessary upgrade.

We often forget the operating system which can be the foundation for doing work at all. As its age goes up it will develop more security risks. If it's not being supported anymore, you are at major risk and need to find a solution.

In this case let's consider risk as regulatory (like HIPAA) or agency risk, with a rating from 0-5 where five is the greatest risk and zero is no risk at all.

User impact and financial impact are subjective but let's rate the impact from 0-3 where 0 is no impact at all, and 3 is high impact.

Disaster resilience can subtract from your score by creating situations where you can be back online quickly. This can be achieved through programs that minimize downtime. Using a virtual machine and a solution like Datto can get you back online quickly even in the event of a total loss, creating lower overall risk.

If you use the equation provided and come up with a number greater than 10, it's definitely time to start talking to an IT professional. If we take the example we had previously, we get these numbers: 15+16+5+3+3-1=42  Every increment beyond 10 should have been a red flag. 

It's also important to pay attention to what vendors are saying. Obviously, there is no guarantee on any system but when you're not given an ETA or an escalation path in case of an outage, you're skirting with downtime and potential costs associated with such.

Remember, if a system is not critical, will cost no time, will not be missed, has no critical or useful data on it, and can be gone forever with no impact on you or your business, then maybe it's ok to keep an antiquated system. I'm sure there are some exceptions as well, where a piece of software would cost a lot to upgrade and the upgrade is avoided, but in the end you really need to consider the risk involved. 

If you have questions on operating systems and recovery processes, I'm always here to help. Feel free to call our office at 616.837.6930 and we can talk about how to get your business running as efficiently as possible.
Post has no comments.
Trackback Link
Post has no trackbacks.