The System Context

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.

Contextual Information

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.

Bootstrapping Data

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.

Portability Switches

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.

Compatibility Controls

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

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.

Too Much of a Good Thing

It started with a well-intentioned development team trying to peacefully resolve differences of opinion on everything from how much default memory should be allocated to the default layout of the user interface. By the time they were finished, I feared that I would need an expert system just to help a customer install and configure our software.

We had too many optional configuration parameters. In isolation, each parameter made good sense. In total, they presented to the system administrator a bewildering array of choices. We managed to arrive at a workable solution by creating sensible parameter groupings, with rock-solid in-line help and plenty of examples on how changes to the parameters would affect system performance. Still, I learned my lesson and am more cautious about putting something into a configuration parameter.

A good rule of thumb is that something should be a configuration parameter only if the system can't function without it being set, such as a proxy server. If something can vary in a sensible way, or if you simply want to give your users greater flexibility, make it a customization parameter and provide a reasonable default. The difference is subtle but important. Configuration parameters have to be set correctly for the system to operate , which usually means that they must be set by a person who knows what he's doing (e.g., a system administrator). Customization information, which should be an attribute of some object, may never be set at all.

By the way, in case you think I'm being overly dramatic about needing an expert system to manage configuration parameters, keep in mind that one of the most famous expert systems everXCONwas created specifically to configure DEC VAX computers!

Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
ISBN: 201775948
Year: 2005
Pages: 202 © 2008-2017.
If you may any questions please contact us: