“I think doing variations on a classical theme is a dangerous thing to do.”
Many organisations select a COTS (Commercial off-the-shelf) OSS tool and immediately start thinking about customisations to make it do exactly what they want. That’s one way… but not necessarily the best long-term solution.
Customisations are intoxicating for both CSPs and OSS vendors alike because of the feeling that comes from creating something new.
Unfortunately, OSS customisations tend to lead to the following for CSPs:
- Longer time to commission
- Increased cost to commission
- Increased complexity when it comes to performing vendor patches and upgrades as they are generally designed for the standardised versions of their software. It means the CSP will invariably have to make their own additional customisations each and every time a factory upgrade is implemented
For OSS vendors, customised OSS lead to:
- Longer time to commission for their customers
- Increased complexity to commission
- Increased complexity when it comes to maintaining and supporting customers who are on different versions of your software
Wherever possible, try to work around the core capabilities of the COTS solution and the vendor’s road-map for new features. Try to do so by evolving your processes and OSS data to suit as it is likely to cause less long-term head-aches. Handle non-standard functions by exception if possible.
Note: There are sometimes terminology confusions when using the word “customisations.” I am using it in the context of making software/code changes to an OSS. Conversely, I use the word “configurations” when describing the changes to the OSS that impact the way it performs but without requiring code change. Examples might include changes in OSS database content (ie reference data) or changes to option check boxes. Configuration changes are a necessary part of setting up an OSS for a specific CSP’s needs and generally don’t lead to the same impacts as described in point form above.