Best practices for making an application customizable?

Question

I'm interested in reading about the various ways other developers and architects deal with the customization of certain areas of their applications for certain sites. Call outs to customer implemented pre and post processing, events doing the same, allowing business logic methods to be overridden, using strategies with pluggable modules, data configurable processes, e.g. rule engines, scripting, etc.

The list could go on, but I'm asking who used what and what the pros and cons are of each of these approaches, as well as what other approaches there are.

This assumes we don't create a customer specific code branch to accommodate these customizations.

Answer 1

I would tend to build everything modular and then adding things to the program as the customer asks for them. You can combine this with application settings that the customer can control, allowing them to add and remove modules on their own. In that case, all you would be doing is setting a default configuration.

Answer 2

For the products I work with, customizations that are built either by the Services group for a given customer, or sometimes by the customers themselves, get shared to the rest of the team (for stuff we've made) and often get "productized" in later releases.

We support a [nearly] full-access API which can be used to do [almost] anything the GUIs can do, but in an automated fashion.

We encourage customers to write custom scripts and then share them back with us. Growing the available uses of a product through extensions, whether they be officially supported, or remain community tools, helps to engender goodwill amongst your customer base.

For customizations we build, the initial work, while billed to a specific customer, can then be implemented rapidly elsewhere, allowing current and future users mroe flexibility when using the product.

Answer 3

MS is working on two different frameworks for this in .NET: the Managed Extensibility Framework and System.Addin.

Probably the most commonly used way applications expose extensibility is through Dependency Injection/Inversion of Control mixed with runtime type resolution. That means, you let an external entity "inject" the implementation of an interface at runtime instead of binding to a specific implementation at compile time. Your code doesn't care if your IRepository is written by your company or by a 3rd party. By coding against interfaces and using DI/IOC frameworks (this link provides a great overview of .NET frameworks) you allow your application to be easily customizable.

Answer 4

One way would be to embed a scripting language (python and javascript seem to be popular) and expose significant chunks of the API through the scripting extension. You might find it easier to implement parts of your application in the scripting language, too.

Answer 5

I've found that creating your app as a library of modules accessible from a good embedded scripting language (Lua was created exactly for this!) gives you tons of flexibility, not only for users; but for yourself too.