How to design a configuration hierarchy?

Generating the hierarchy between configuration and parent configurations is like designing an object class tree. Many books have been written about it, but you surely have not the time to read them now.

I see it this way: You can choose either a pragmatic or a functional approach.

Pragmatic approach

In the pragmatic approach, you first write down all the configurations you need with all their parameters. You then check out whether you can build groups of configurations that have lots of common parameter values. Those common parameters will be moved to a parent configuration. The quality goal is: to have as much common parameters as possible. Don’t care about the meaning of the configuration-hierarchy.

Functional approach

In the functional approach, you try to identify functional groups of parameters. Those are the parent configuration. The quality goal is: the system of parent and parent-parent configurations should reflect the expected dependencies of the different software-subsystems you use. Don’t care about the economic aspect!

For example: Under ORACLE, you have

1. lots of parameters depending from the installed version of the RDBMS (tools and directories),
2. lots of parameters for the machine you install your database on (pathes for various files, data and index drives, machine name and IP-address, disk and memory limitations) and
3. parameters describing the instance to build (SID, service names, init.ora-Parameters).

So at least you can have the three parent configurations _ORACLE816, MY_SERVER. MY_INSTANCE, which together they build a THIS_INSTALLATION configuration. And if you have to deal with many ORACLE-Versions, you put the common settings to an _ALL_ORACLE  and give it as parent to _ORACLE816.
More exactly: if you need the full path of SQLPLUS.EXE, you set

_ALL_ORACLE.SQLPLUS = ${DIR_ORA_BIN}\sqlplus.exe
(tool name ok, but path as to be defined yet)

and

_ORACLE_816.DIR_ORA_BIN=d:\oracle\ora816
(with parent=_ALL_ORACLE) (resolves path)

If you later add a ORACLE817 installation, you simple must create a

_ORACLE_817.DIR_ORA_BIN=d:\oracle\ora817

and replace _ORACLE_816 in the parent configuration list of THIS_INSTALLATION by _ORACLE_817.
Got it? So with just two additional definitions you switched your database generation script from ORACLE 8.1.6. to ORACLE 8.1.7.

If in doubt, use the “sociologic approach”

I have no clear recommendation about the right approach. The “functional approach” is clearly the better one, especially for large sets of configurations (and this is SCRIPTOR was made for), but you will spend a lot of time speculating about things like “will they change the name of this utility in the next release? Is the amount of memory for my database a constant for  the whole project, or is it a property of a specific instance?”

Don’t think too much, you’re wasting your time. It’s like predicting the Dow Jones for next month!

I think your configuration hierarchy is O.K., if you can explain it to another person in five minutes (“sociologic approach”).