If it ain’t broken, don’t fix it. We’ve heard that before, supposedly some 1950s Russian manufacturing principle; most people in IT even swear by it. Ever experienced 72 hours of sleep deprivation just to undo a “simple patch” that’s suppose to take 30 minutes to install? We’ve all been there before.
So this “programmed” behaviour leads to stoic, “NO First” attitude when it comes to system enhancements. “NO First”, even happens for any critical patches, operations folk shudder and think up workarounds like “Great Walling” the IT systems with 3 different brands of Firewalls on top of the 2 Intrusion Protection Systems with the false belief that if nothing can get in, everything will be fine.
IT systems go through “revolutions” as system resources, users, business functionalities and complexities skyrocket on a daily basis. A system that is not built for change goes bonkers the moment anyone does anything on it.
What does that tell you? Well, it tells me that the system is FRAGILE by design, and built atop a deck of cards. Inter-dependencies abound and patching or system upgrades are more like deft manoeuvrings on Jenga blocks. Admit it; we behave like children, and upgrades only happen through irrecoverable failures!
Take a second to mull, are your IT people ruled by “Failure Induced Change” or is it “Built for Change”.
Built for Change is a methodology to eliminate old school architectural principles of plunking behemoth systems with quadruple redundancy that's CEMENTED IN SITU, requiring a whole IT department to sustain and nurture before it can sputter menial reports.
It’s also about “de-programming” – “If It ain’t broken don’t fix it” mindset.
Built for Change means thinking about how the system can still run at 10,000 rpm while undergoing daily upgrades and code fixes as customers point out better ways in using your software.
Are your Technology Investments Built for Change?