Customisation or Configuration?

Following on from Peter Batty's topic and as something that has bothered me over the last year ...

The usual definition given for the configuration vs customsation dichotomy in terms of non-code/code is a good starting point but there is more to it than that. Often it is helpful to look at the context and issues around a term rather than get hot and bothered about its definition. Here are a couple of other ways of looking at it:

Firstly, there is, of course, the Total Cost of Ownership issue. Customisation leads to unpredictable total cost of ownership for systems. This is made up of the cost of building the customisation in the first place, the cost of supporting the customisation (including the cost of handling problems at the boundary of the customisation and the product) and, the scary one, the cost of migrating the customisation to new versions of the product. All of these are high risk and involve the user in areas that are not core to the business. An option here is to out source the activity and the risk.

The other way of looking at the distinction is in terms of what happens to my configuration and what happens to my customisation when the product version changes. With configuration the expectation is that the configuration is migrated seamlessly to the new platform, with customisation this is not expected to be the case. A parallel distinction is in what is supported and what is not - the product is expected to support my changing these this (configuration) but not that (customisation).

Both of the above avoid the need to use code/non-code to distinguish between customisation and configuration and this is good because there are times when 'changing a few parameters' is either too cumbersome or more complex logic is required. Scripting provides a means to do so and scripting through some form of DSL should not in principle be excluded from what is configuration. However in practice the way that scripting is currently managed is not going to cut the mustard. The difficulty is that the 'scripts' usually sit outside the system and are stored as flat ASCII. This leads to problems when the product, for instance, changes the name of a table, adds a new parameter to a function or even removes a function.

Amongst the things that people look for when they require the product to be extended are:

• Task Automation - This will involve getting data from the GUI (for instance the currently selected object), pushing data into the GUI (putting data into a text field) and triggering actions (pressing the 'Insert' button).
• Business Rule Validation - On entering data into the field, the system will fire any 'hooked-in' validation rules.
  
• Loading Data - This is either data from legacy systems as part of initial migration or on going alignment of data between systems.
  
• Dumping Data - This is typically in the form of a report, but may also be a data export to another systems.

Now all of the above do not necessarily need scripting. For the last two, there are standard ways of doing this for simple tasks and there are 'data alignment' products on the market if the task is complex. For the first, a macro/record facility would meet most needs and for the second, many validation rules can be configured into a rules engine. An observation about all these solutions is that they are all different; require different tools and skills (even if those tools are off the shelf). The temptation is to go for the 'scripting language' path as this can meet all of the above and more.

As Peter points out though, as the application becomes more tuned to a particular domain, it is expected that it includes all the things that the customer wants. Another way of putting this is that the product encodes 'best practice'.