Before worrying about the technical details of structuring configuration parameters, let's take a step back and consider what should be configurable. The basic information that needs to be captured in these parameters is the system context that is, all aspects of the contextual information you need for a properly functioning system. By capturing these data and making them configurable, you provide your customers with the ability to set key parameters at deployment instead of during development. This process of late binding makes your system more flexible and far easier to deploy.
Identifying contextual information is the job of the tarchitect, as informed by key members of the development team. Here are some specific areas to consider.
Location of Key Files and/or Directories
Many complex systems rely on predefined or well-known files and/or directories whose locations are set during system installation and captured in configuration files for the runtime environment.
Most technical systems require various kinds of bootstrapping information. Your computer requires a BIOS. Your application requires an entry point for the operating system to begin executing the program. Enterprise-class systems usually require bootstrapping data stored in files in precisely named files and carefully located directories. The most common choice is a subdirectory under the subdirectory containing the application, with one or more well named configuration files. Note that even these bootstrapping data can be lost, and a good defensive design technique is to ensure that the system can perform a reasonable minimum set of functions without it.
A special context is one that deals with system portability. For example, a team that worked for me designed a system that could be configured for use with Oracle or SQLServer. The choice was important because the system used slightly different SQL statements that had been tuned for the performance characteristics of each database.
Development teams face challenges in determining how to support older versions. Instead of making this decision arbitrarily, turn it over to your customer and let them decide via any number of configuration parameters.
Performance parameters range from timeout values to in-memory storage requirements to the number of database connections the system should automatically maintain. Truly sophisticated applications can adjust these parameters based on self-monitoring system performance, but most of us can get away with allowing the user to configure with simpler parameters specified at system startup.