Have you ever worked on an OSS where a COTS (Commercial Off-The-Shelf) solution has been so heavily customised that implementing the product’s next version upgrade has become a massive challenge? The solution has become so entangled that if the product was upgraded, it would break the customisations and/or integrations that are dependent upon that product.
The OSS then either has to:
- skip the upgrade or
- take a significant cost/effort hit and perform an upgrade that might otherwise be quite simple.
If the operator decides to take the “skip” path for a few upgrades in a row, then it gets further from the vendor’s baseline and potentially misses out on significant patches, functionality or security hardening. Then, when finally making the decision to upgrade, a much more complex project ensues.
It’s just one more reason why a “simple” customisation often has a much greater life-cycle cost than was initially envisaged.
How to reduce the impact?
- We’ve recently spoken about using RPA tools for pseudo-integrations, allowing the operator to leave the COTS product un-changed, but using RPA to shift data between applications
- Attempt to achieve business outcomes via data / process / config changes to the COTS product rather than customisations
- Enforce a policy of integration as a last resort as a means of minimising the chess-board implications (ie attempting to solve problems via processes, in data, etc before considering any integration or customisation)
- Enforcing modularity in the end-to-end architecture via carefully designed control points, microservices, etc
There are probably many other methods that I’m forgetting about whilst writing the article. I’d love to hear the approach/es you use to minimise the impact of COTS version upgrades. Similarly, have you heard of any clever vendor-led initiatives that are designed to minimise upgrade costs and/or simplify the upgrade path?Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email