I’m in danger of sounding like an episode of Grumpy Old Men, but “We’re Risk Averse” is another of those expressions that grates a bit for a database support consultant. In my previous blog (If it ain’t broke, don’t fix it) I mentioned one expression that stores up problems in the long run. This often strikes me as another.
Now, on the face of it, there’s nothing wrong with being risk averse. Unless you’re Bear Grylls or Sir Ranulph Fiennes, viewing risk as something to be avoided is a smart move. Risk sounds like you might damage something (although the definition is actually “ the potential of gaining or losing something of value”) but really it’s just that you might change something.
So, if you suggest to a customer that they might want to look into moving to a new version of DB2, then that sounds like risk. And why introduce risk to a critical area of your business software? Why expose your own users and customers to down-time and possible changes in the behaviour of the application that might be negative?
Well, one reason is, of course, if the software is going out of support. I’m sure we’re all aware of the impending out of support dates for some versions of DB2 this year (DB2 Distributed end of support (EOS) dates) and here at Triton, we’ve still got clients who are running V8.2, never mind 9.7 and 10.1. I try not to sound like the harbinger of doom, but I do find it a bit alarming when you point out that a mission critical database is either now, or soon will be, out of support and there’s not much enthusiasm for changing things. At the low end of the excitement level is “well; it’s running OK at the moment…. We rarely get any problems” and at the high-end is “ooh, we don’t want to do that; we’re quite risk averse here”.
Two things I guess:
- Would you not judge it to be a bigger risk to have your database software no longer supported by the manufacturer? You know that thing with your washing machine? It’ll come with a 3 year guarantee and 24 hours after the 3 year guarantee expires, it’ll go phut. DB2 is terrifically reliable and robust but it’s still software and it could still go wrong. I’d rather have my database reliability guaranteed by the manufacturer, and have access to a formal support process
- That definition of risk included “the potential of gaining value”. Each version introduces new functionality and features and you can take or leave them. If you’ve an aching need for one of the new options then, yes, you’d conduct a Proof of Concept exercise; asses the benefits versus the risks; run the new version in a test of Dev environment for a good long period of testing. But some of the benefits just appear out of the box. V11.1 for instance introduces BLU query performance enhancements without any change in the code or settings; it just does stuff more efficiently.
Of course you’d mitigate the risk of adverse effects by testing the new upgrade in a non-critical environment, but surely it’s not worth dismissing it as ‘too risky’ just because you haven’t had a major failure in a long time, and because it’s been years since you raised a PMR or Support Call with IBM.
Not upgrading to a fully-supported version of DB2 isn’t really risk averse at all; its allowing negative risk to develop through lethargy.
And, next time, I promise to have something more positive and uplifting to blog about.