Customization vs Configuration
I had an interesting philosophical discussion with one of my colleagues about the level of customization you would do for any given product deployment.
By customization I mean building specific scripts and infrastructure that goes beyond what the product was designed to do; this is going beyond what a product was designed to do. Contrast this to configuration, whereby the product is deployed and run as designed with only on-site modifications being changes to configuration items; this is keeping within the bounds of a product.
So why would you want to customize or extend a product beyond its current design? In many cases there are business and/or technical requirements which dictate that a task or business operation cannot be achieved without some level of customization. The outcome is a deployed solution that meets the requirements in the immediate term. On the flip-side you get a deployment that is very specific and unsupported, which means that it is likely to be incompatible with future core product releases. The cost of this is time (and ultimately money) to keep this custom code up to date, not to mention educating new users/operators as to the specifics of your deployment. Max Goldman echoes similar thoughts in his blog
In an ideal world your product would be flexible enough to be configured to meet a wide variety of solutions. Deployment would be down to configuring your product to do what you want, how you want. If there’s anything you currently can’t do, then the framework in your product would allow you to quite easily add this in, without customized code.
Nevertheless customizations exist for a reason and serve to deliver key functionality before it is available in the core product. These “stop-gap” solutions can often be the difference to a successful deployment, and as such fill a vital role. In the long-term, the key is to ensure that the features which they provide make it back into core product so deployment becomes a case of simple configuration.
RSS