System Configuration
A new piece of software rarely works 'out of the box'; it will require some form of configuration to meet your specific requirements. Even when loading standard packages such as Microsoft Office onto your PC you are presented with a range of options such as 'do you want clip art loaded thus increasing the disk space needed for this application?' The choices available within complex software applications can be many and the implications of initial choices far-reaching.
We are getting into the more technical aspects of implementation here but before the project champions and end users among you decide to skip this section there are aspects of the topic you need to understand, such as the difference between configuration and customisation discussed in this section. You may need to take key decisions about issues such as user security rights or how to set up lists of values in reference tables. Ensure that you work through the full ramifications of the possible options. Looking at common scenarios, or use cases, and working them through from start to finish can help you explore the way in which one piece of configuration may affect how you carry out a process.
System configuration applies to either hardware or software, or more often a combination of both, and refers to the essential process of setting up the assortment of hardware devices, operating systems, system security controls, user access rights and responsibilities, technical system resources (e.g. interrupt requests, direct memory access channels, input/output memory addresses), software programs and lists of values within data tables (and mappings between these values) that make up the entire system.
Configuration of a piece of hardware may require switches to be adjusted to particular positions.
Configuration of software usually requires certain parameters to be set to specific values so that information can be passed from one computer program or programmed routine to another to define the characteristics of the data being processed or the circumstances of the transaction taking place (e.g. a specific error message needs to be displayed because the code entered is invalid; the next cheque number to be used is "000239752"; this student's details need to printed in the specified format for Form 10A).
Suppliers often supplement the extensive functionality of their software by providing greater flexibility and/or extended capabilities. This flexible or extended functionality comes about over a period of time because users of those systems request enhancements that may be valid only for their types of operation.
Suppliers are then faced with the challenge of:
developing the particular version of the software being used by that individual customer to include the specific enhancements;
incorporating the enhanced functionality within their standard products for all to use; or
allowing the program's logic to be configured to work in different ways by different organisations.
Suppliers rarely agree to the first option because it leads to the huge overhead of different versions of the software being developed and maintained for each different customer. The second option is feasible only if it is an enhancement that is required by all customers, and because suppliers want to satisfy the requirements of more potential customers, they are inclined to provide the more flexible second option that requires users to configure the software to meet their specific requirements.
The key to a well-tuned, trouble-free system is to understand the ways in which it can be configured and to ensure that it is appropriately configured. A properly configured system helps to avoid resource conflict problems and makes it easier to add new equipment, but an improperly configured system can lead to errors and problems buried deep which are hard to decipher.
The third option should be approached with some caution as this may hide a plethora of later headaches. Things to check are:
what is the extent of the support for this flexibility? For large-scale internationally-marketed products this is usually down to a geographic 'localisation' of the core product - e.g. different versions for the UK and US markets.
is the flexibility 'upgrade-proof'? This tends to be more the norm now, but beware software where careful re-configuration is necessary every time there is a software upgrade. This may still be acceptable however depending on the scale.
It goes without saying (although unfortunately still occurs too often) that local customisation (as opposed to configuration) of a product in a manner that is not approved by the supplier should never be attempted - system errors and upgrade problems aside this is guaranteed to invalidate any warranty on the product and can leave you with an unsupported, unworkable system. Customisation is looked at in a later section.
To properly configure the system, you will need to know how much hardware and networking equipment will be required to operate the software, exactly how it intends to use the software's functionality and the level of integration between the new system and other existing systems within the institution.
