What starts out as a successful quick-win turns into a low-leverage intervention that causes more trouble than its original root cause. With the advent of IaaS and SaaS the example used in "fixes that fail" seems a little dated, truth being I haven't had time to update it, however the central principles are still valid and very much applicable in our organisations (first published in 2009).
Fixes that fail: Decommissioning from Systems Thinking IT
When I started looking at the world through models the penny dropped, the overwhelming feeling was "IT people must know about this". That was in 1994 and I've been banging on about it ever since.
The system archetypes are in control and it is very hard to do anything about it, but if we don't try, what does that make us? I talk about this in the conclusion of Sea of Systems "well at least I helped this one".
I explore this and other system archetypes in my eBook Sea of Systems, download it at my blog https://systemsthinkingit.blogspot.com.au
When I started looking at the world through models the penny dropped, the overwhelming feeling was "IT people must know about this". That was in 1994 and I've been banging on about it ever since.
The system archetypes are in control and it is very hard to do anything about it, but if we don't try, what does that make us? I talk about this in the conclusion of Sea of Systems "well at least I helped this one".
I explore this and other system archetypes in my eBook Sea of Systems, download it at my blog https://systemsthinkingit.blogspot.com.au
I think that SaaS is a great way to decrease this risk but for those organisations that own private clouds or even commission virtual servers via AWS the lesson is still very relevant. The example shows how Fixes That Fail works as a system archetype - try to assimilate this into your own environment, I'm sure you'll be surprised at the number of "high leverage" / "no-brainer" interventions that actual fail over the mid and longer term horizons.
ReplyDelete