Configured vs. Customized Software- Some Control Similarities

Most modern Laboratory Informatics software packages have adopted “configurability” as a marketing and functional focus.  In the old days of laboratory software package implementation, it was quite common for a company to customize the product for their particular use.  At the time, this was seen as maximizing the value of the product by matching business operations. These days, as laboratory software implementations implement principles from other business-related IT projects, the emphasis is now placed on using software packages that can be configured for specific use instead of customized.

Customization of software in the laboratory has become undesirable since customizing a software package means the following:

• Creating or paying for customized code creation
• Documenting the customized code
• Fully testing / validating the customized code and its interaction with the base software
• Deploying the customized code to different working environments (development, test, production, or other instances of the software) in a controlled fashion
• Controlling change to the code and the base software
• Maintaining the code over time as the base software changes version or as business requirements change.

The recent trend is for companies that deploy LI software to refrain from changing the core software themselves and leave software maintenance to the software vendors. Instead, a good choice is to choose LI software that uses software settings (”configuration”) to achieve changes in the way that the software operates.  This kind of software has to be designed properly from the beginning to include this ability and indeed much of the software available today does a good job of allowing the operation of the software to change significantly without requiring customization of the base product.

Choosing the path of configuration does solve some of the problems outlined above. Configuration changes generally don’t require:

• Coding skills or paying for these skills
• Full testing and validation of the change; while the configured system must surely be tested, a customer can leverage the vendor’s thorough testing of the configurable system as a starting point
• Maintaining custom code through version upgrades of the software. Presumably, software vendors will support configuration options from version to version.

Because software configuration changes can dramatically change the operation of software, using configuration options in software doesn’t relieve the need to:

• Document the system configuration settings
• Test the intended configuration use in the system
• Deploy the configured settings to multiple environments
• Control changes to the settings in the systems including showing a history of what configuration changes existed at a point and time and showing how changed them and why.

Whereas custom code has historically been stored in code repository software in order to maintain traceability and deployability, software configuration settings have to be maintained in a configuration management system for the same reasons.  This system could be a manual, document-based system or it could be an IT system.  If the proper controls are not able to be placed on the configurations, though, a configured system is no more controllable than a customized one.