Risk Taking And Cost Savings On IT Systems TCO

Every day we take risks, some would say just getting out of the bed is a risk taking activity. But what does it mean to take risks at work? And more interestingly how do we save money by doing this? There are some interesting answers to both of these questions and there is definitely no right or wrong answer. What is interesting, and this is what I would like to elaborate a little bit about, is how today’s technology that we are using at work allows us to tie the two together.

If you have an IT environment that contains mission critical systems, systems that will stop your business, one of the options you have at your disposal to reduce MTTR is to pay for 24x7 vendor support. Typically with this SLA you get vendor to respond to your cries for help any time of day or night, so you are not really taking any risks here. The unfortunate side effect of having this level of coverage is that you are paying a premium price.

And here is where the risk comes in to play. Before you start down the list you need to make sure you have a good grasp of your IT environment and impact of individual systems to your business

Is The Risk Worth It? Answer These Questions First

  • How critical is the support?

    • Decide if you need to be paying premium vendor SLA price for systems that you can live without for few days. Obvious candidates, low risk items, are your non-production or development systems. However you need to look at production systems as well and weigh the risk of reducing vendor SLA.
  • Analyze your systems architecture, what levels of redundancy do you have built in?

    • If my system has multiple levels of redundancy and I can run my service even when one or more parts of that system are hard down – this could be flagged as low risk and potential to save some money by reducing vendor SLA, no need for premium support. Result of this analysis may prompt you to invest some time and money to bring your systems to levels of redundancy that will reduce the risk of impact to business, thus making them a candidate for SLA cost reduction.
  • Should you update your systems and hardware?

    • Most vendors will provide 3-4 years of warranty that includes 9x5 SLA. Spending capital on replenishing your HW so that it stays within warranty period is another option to reduce TOC and maintenance cost year on. If you cannot afford to do this (at least on some equipment) then you are running a risk of increasing your maintenance cost and even running out of maintenance in case of EOSL systems. Not a good idea if you trying to run a 24x7 business.
  • Should you go virtual?

    • A colleague of mine posted an article on virtualization and the benefits we reaped in one of our projects. This is really a no brainer, reducing number of actual HW systems in the environment will reduce the TCO in the long run and risk of failure of the environment is greatly reduced by employing fully redundant configuration. Have a read, it is a very good article on the subject.
  • Do you have the right people?

    • If you have skilled IT force and you are confident that they will deliver best MTTR after an incident, it may be worthwhile investing in people rather than maintenance support. Another factor that should influence your risk assessment.

While you may not be the favorite client your vendor has after you go through this review and cost adjustment, the exercise is worthwhile and should be done regularly. Today’s technology and how we use it allow us to save a chunk of money in every day running cost of our IT environments. Every organization should be able to make some changes in this space, however it is not one of those risks that you want to take without good analysis of your environment and your requirements.

Have you taken a risk in your IT environment? What were they and what were the results?

Nedo Kopcic has been working in IT for the last 21 years, specifically around infrastructure and operating systems. Nedo has been working at Intel Ireland for the last 10 years.

Find Nedo on LinkedIn

See previous content from Nedo