Forces of Chaos
#2: The Unintended Upgrade:
But we already bought this product!
In this series of posts we explore why many organisations find themselves fighting unruly technology. We'll look at where the complexity comes from, and the weapons and tactics needed to control it.
You have been told your servers have to be replaced although there's nothing wrong with them.
You can't use some new features of the software that you need. If you want them you'll have to upgrade your database server at horrendous cost.
One application has a permanent warning banner that can't be cleared.
In recent years software has intruded deeply into our purchasing of information technology and how we run our organisations, arrogating itself rights traditionally exercised by the purchaser.
Unlike a physical product, software can mutate after purchase at the whim of the vendor. Most times you're not even buying the product, merely renting the right to use it while granting broad freedoms to the vendor!
Software can stop working or lose features when the vendor withdraws it from sale or releases a competing product.
Software can disable functions, or refuse to work fully unless separate software dependencies are purchased and installed.
If you defer upgrading some software for too long, you may find that a technical incompatibility prevents you retaining all your data when the upgrade does happen.
Businesses can defend against these indignities with a mix of prevention and remediation.
To begin with, you'll need a detailed and up-to-date inventory of all your software. A service provider will usually have automated discovery software of some kind, or you can set a tool up permanently. It's unwise to rely on manually created records, as software can often be installed anywhere, at any time.
A technical architect (talk to us at WT, or call your service provider) can advise you on the life expectancy of your software and assemble a roadmap that forecasts when products will become unsupported or will need replacing.
An architect can also advise if certain products present growth or dependency risks and recommend options for reducing this.
Your business will need to develop a corresponding budget and the management discipline for getting the roadmap's upgrades done, so that you do not accumulate dangerous levels of technical debt. This means that some upgrades will happen while your software is still working fine, but that's always preferable to the alternative, right?
Your upgrades should be visible on a long-term technology roadmap.
Well chosen products should impose fewer upgrades, and these should occur safely and quickly.
Your business should track technical debt as a corporate risk, and invest accordingly.
Recent
A series on the forces that disrupt your information technology and your organisation.
Soon:
- #3: Was that part of the plan?