Almost every CTRM implementation needs some level of customization or extension to meet business requirements. This could be as simple as a custom data element or as complex as custom code written in a language such as C#, Java, or SQL that bridges a gap between the CTRM and the business requirements. Each vendor will have a process they follow for creating and supporting the customization. The following are three key thoughts to keep in mind as you go through the process of adding customizations or extensions to your CTRM platform.
Error Trapping / Logging
Recently, during an Installation Evaluation (IE), it was discovered that the one of the customer’s primary extensions to their CTRM had no error trapping or logging built into it. When a problem arose, all they were presented with was an error that made no sense to them and gave no visibility as to how to solve it.
Error trapping and event logging should be required in any extension where custom code is written. The trapping and logging exist so that when a process fails, it does so “gracefully” and provides users and administrators as much information as possible to solve the issue without needing someone to review the code. Error trapping and logging should also be a part of the test cases that are defined as part of the customization.
Testing
One of the areas that is often overlooked in CTRM customizations is testing. Clearly defining all test cases should be a pre-requisite to starting any development on a customization. The test cases should all have expected input and outputs to validate the extension. This is standard practice even if we do not find it at every client site.
Where most testing is deficient is around negative tests sometimes known as ‘unhappy path’ or ‘sad path’ testing. Working in conjunction with the error trapping/logging mentioned earlier, negative testing works to provide a more resilient solution to the customer. In the case mentioned earlier, at least one negative test case would have helped to catch the issues with the customization and steps could have been taken to fix the issues around error trapping.
Documentation
Documentation for a customization needs to be thorough. It should fully document the reason for the customization, the parts of the customization, the expected outputs and test cases of the customization, and the installation of the customization.
All too often the documentation for a customization or extension is lacking. Sometimes the documentation is an afterthought or is thrown together after the customization is already in production. Typically, the documentation for a customization would be provided in a detailed document that contains all the information about the customization. With the prevalence of screen recording, video is also becoming another way to document customizations, and it can sometimes be more efficient. Regardless of the means, documenting a customization is paramount for long term supportability. Clearly defining all documentation and expected deliverables upfront mitigates the risk of a poorly documented customization.
