Continuing a series examining certain arguments for buying commercial software an minimally customizing it versus custom-developed software.


All but the simplest COTS (Commercial, Off-The-Shelf) software will need customization. While is impossible to accurate assess how much, it is possible to determine what portion of in-house resources go towards needed customizations versus integration with other systems. If the integration is complex and problematic it can take time and expertise away from providing business-critical customization. If the users go without their needs addressed because everyone with any expertise is struggling to make the software talk to the rest of the systems, where is the value in that?

Programming Interfaces

A critical aspect of vendor application customizability is a powerful, well-documented, flexible and stable set of APIs that allow the customer to modify the behavior of the software without introducing incompatibilities and dependencies that cause problems in later upgrades. The question to ask is, are they the right interfaces? Are they sufficient to allow the right customizations without being overwhelmingly complex? Do they make the common, simple case easy, and still make the hard things possible? With custom-developed software, the interfaces are, by design, the ones need to address the business requirements. If the APIs stop meeting the evolving needs of the application to address user requirements, in-house developers can refactor them to be more flexible and useful. For purchased applications, these kinds of changes must go through the vendor’s change process, and a single customer’s needs are not the highest priority except in unusual circumstances.