If architecture were to be the tower of babel, configuration is its language
As the story goes God devised multiple languages so that men can't build sturctures that span to the heavens. In our small world of programming architectures the men and women of the world are quite busy (with out much help from any Overseer) constructing a confusion of their own. The name of this confusion is called "Configuration".
The larger and more complex an architecture is the simpler its constituents need be. That means the key for complex programs are pluggable parts or pluggable functionality at run time. Almost like a self-evolving system. The key to accomplishing such a composition is configuration. We seem to invent for every configuration need a different configuration api.
Sometimes configuration is read from properties files. Some times from XML files. Sometimes from System.properties. Sometimes passed in as a properties object. Sometimes read from multiple config files. Sometimes libraries use a different confgiuration than applications.
Such diversity of configurations exists because it is fairly easy to read configuration at run time. So it is left to the individual programs and components to determine their own needs.
But I am realizing more and more that it is the configuration that holds an architecture together. When there all the parts and containers use the same understanding of a configuration then it is lot more easier to integrate parts from varieties of sources and manage them well. The key to this understanding is to arrive at a unified abstraction for configuration that is based on the "structure" of the data rather than the form. This insight is as important as knowing the difference between XML and an InfoSet.
Once the configuration is perceived as a hierarchical set of data nodes that are not tied to implementation, then it offers a great flexibility to know that every component and part in an application can use the simplest of the APIs to realize their configuration needs. Having an interface to configuration is very important as all the components of an application, including the container can use the same api.
You might parallel this to a windows Registry. It is subtly diffrent from a windows Registry. Befor going there let me say the only good thing I can say about windows Registry. Registry allowed "COM" components to succeed and florish. With out this common understanding it would have been difficult to accomplish to interoperate. Now the problem with Registry is not because it is one big blog, but because it is not an interface. Had that been an interface, application would have been able to pick and choose where to keep their own configuration without interfering with the rest. The second improvement is that this interface needs to be small.
Some of these aspects are discussed in greater detail at the following article at the following O'Reilly link