What is the difference between customization and configuration?
This is a commonly asked question, and a brief comparison of these terms is in order:
|Definition:||Change of the code/logic of the product||“Tweaking” of product parameters to achieve desired functionality|
|Who does it:||Developers, architects, and other technical team members||Business users, with some training or manuals|
|Timeframe:||Weeks, months or years||Generally an order of magnitude less than corresponding customization timeframe|
|Transparency:||Requires access (white box) to the product code||Does not require access to the product code|
Would you rather have a product that is customizable, or would have a product that is configurable? Product managers eat questions like this for lunch. Any day, a more configurable product is what the product managers aspire to have. “Customizing” products is almost an oxymoron – it means that we are going to be writing custom logic to do what the product was not able to do. For large enterprise products, customization may be necessary, and while customization may yield some services revenue, the prospect of requiring customization may actually cause an impediment in the sales process itself. If the product is configurable, it is more appetizing to the customers, and they can quickly fine tune the software to their needs.
Related term: Implementation
The related term “Implementation” means the actual work done (configuration, customization or the combination thereof) to satisfy an actual set of business needs. Implementation is a more encompassing term, that can include deployment, configuration and customization to meet the customer’s requirements. For example, when a client buys NetSuite ERP or BizMerlin, they can deploy the software, configure all the aspects of the software, and then possibly write custom code to enhance the functionality even further.
Related term: Extension
Many software packages have extension capabilities that allow you to customize their behavior by writing custom code within the framework. Custom code can be written in the environment provided by the package, and is usually one of interpreted languages, such as Drools, etc. Having the foresight to allow extensions is a sign of maturity of software and allows the original software provider to allow other developers to write “custom apps” or “plugins” within the software’s ecosystem. Read more about how providing an ecosystem helped a new entrant beat out the established market leader here.