Well there’s an imperative. Deviate for resilience. Which goes waaay beyond mere ITCM or its linkage into BCM. What I mean here, though, is a reflection from the B side into the IT side.
Once encountered when it was still supposedly somewhat ‘cool’ (as it was called in the grandpa’s days) or so to work on … can you believe it, $AAPL infra. Where the Infosec staff had carved a corner for themselves: That they’d actually need to deviate from corp policies (the devolved kind) of using M$ stuff for alibi reasons of needing in ITsec par excellence, a fall-back that would actually work when all of the M$ infra would’ve collapsed due to some class breaking glitch exploit. Yeah. That meant that you did need a substantial budget to your own discretion without much transparency towards effectiveness of spend and no gadget and toys buying, right?
Nowadays, the coolness if ever it truly was (stupid sheeple), has worn off totally and is a tell for no comprendre qua cost/benefits analysis, sufficient tech-savviness to cut it in today’s world, and forward compatibility even to the cable mess (costing you tons). Predicting which unicorns will succeed, or fail, is easy; the former are on M$, the latter on … you guessed correctly. Nevertheless, the resilience argument still holds.
Which goes beyond the mere platform choice. It goes for global/local deviations as well. IF yes that’s a big if, if done right, not for NIH purposes (both ways ..!) but for resilience purposes. It’s not efficient to the max, but if you strive for that, you’ve done so much wrong already it might be irrecoverable. E.g., mission, organisational culture, risk management (incl analysis), control choices and implementations (case in point: multiple malware scanners), etc.
But remember: When done right, you very probably do need to deviate all over the place for resilience…
Just remember that to defend yourself, OK? And:
[If telecom fails due to clock synchro errors, it’s still a sun dial (really it is); Barça]
