There is a version of ERP and business software delivery that everybody recognises. The product fits about eighty per cent of the requirement. The remaining twenty per cent is customised. Two years later the system cannot be upgraded, the customisations are undocumented, and the original engineers have moved on.
The instinct is to blame the customisation. That is the wrong lesson — the customisation was usually necessary. The problem is how it was done.
Distinguish configuration, extension and modification
- Configuration changes behaviour through the system’s own supported settings. It survives upgrades and requires no engineering.
- Extension adds new behaviour alongside the existing system through defined extension points. It usually survives upgrades and is maintainable.
- Modification changes the existing system’s code. It rarely survives upgrades cleanly and accumulates cost every time.
Most requirements can be met by the first two if somebody puts thought into it early. The trouble starts when modification is used because it is faster this week.
Ask what the requirement is actually protecting
A surprising proportion of customisation requests exist to preserve a process that was itself a workaround for an older system. The organisation is not attached to the process; it is attached to the outcome the process protects. Asking what would go wrong if it worked differently frequently removes the requirement entirely.
That question has to be asked with respect. Sometimes the answer is that a regulation requires it, or that a real operational risk sits behind it. But it should always be asked.
Write the customisation for the next engineer
The person who maintains a customisation is rarely the person who wrote it. Naming, structure and documentation are not politeness; they are what determines whether the next change takes an afternoon or a fortnight.
Customisation is not the problem. Undocumented modification with no upgrade path is the problem.
Decide upgrade policy before you build
If the organisation intends to stay current with product releases, that constrains what customisation is acceptable — and it should be agreed before the first line is written, not discovered at the first upgrade. If the organisation is content to stay on a fixed version indefinitely, that is a legitimate choice with different trade-offs. What is not legitimate is leaving the question unanswered.