One possible generic architecture for a system concept would leave uninstantiated all possible design decisions under all possible choices of system conceptual context. This architecture is obviously impossible to provide explicitly to the system builder, although it exists as a model from which the system builder chooses design alternatives.
We normally view the design decision process in its entirety. That is, we view the process as a mapping between this completely uninstantiated generic architecture to a particular system implementation. In practice though, usable generic architectures are those that are partially instantiated with conceptual context and design decisions.
Our goal in generic engineering is to separate conceptual context from system specification concept, and then provide a generic architecture partially instantiated with design decisions so as to enhance its use. These design decisions tend to be "macroscopic" in nature. That is, they are design decisions that fix entire subsystem generic architectures rather than "the small details".
For example, consider a generic architecture for the service layer of a database management system. This system can be viewed as a "layered" architecture. A diagram of such an architecture, together with a sampling of concerns at each layer, appears in figure 2.
The interfaces to the relational model layer, the high- and low-level file system layers, the page management layer, and the disk management layer, are all "fixed points". That is, they are design decisions that are made and become fixed within the generic architecture. Each layer is a subsystem implemented by a generic architecture of components whose contentual context is partially fixed by the concept of the layer below.
A way to view such a restricted generic architecture is as a multi-level architecture. Consider a generic architecture to be separated into a fixed collection of subsystems, each of which implements a single abstract concern. Suppose each subsystem in turn is separated into a fixed collection of subsystems, and so on until we are provided with a fairly manageable subsystem generic architecture whose components can be provided with contentual context to instantiate actual subsystems.
Each subsystem at the top level of such a multi-level generic architecture can be viewed as the content of a single concern, and has as contentual context at least one other subsystem concept at that level.
In practice it is convenient for us to bind this choice of contentual context, i.e., fix the subsystem generic architectures early in the design process. Essentially these subsystem generic architectures become invariant context. Note that what is invariant at this level is not a particular choice of subsystem content, but a particular choice of subsystem generic architecture! One can view this as a "second-order" invariance. In general a multi-level generic architecture can be thought of as an nth order architecture, where n corresponds to the number of levels.
In a strictly layered system such as the database management system architecture in figure 2, the concept at each level of the architecture has a generic architecture as content, and this generic architecture has exactly one contentual context parameter, the invariant contentual context of the next lower level. In practice, a generic architecture as content might have any number of contentual context parameters instantiated with such invariant context. That is, this top layer of our generic architecture need not be strictly layered. For a diagram of such high level interconnection, see figure 3.
Consider the top level of a particular subsystem generic architecture. At the next lower level, this architecture can in turn be either a fixed architecture of subsystem generic architectures, or a generic architecture that must be supplied with contentual context to be instantiated. This process is repeated until all architectures (those at the bottom level) are generic architectures that must be instantiated with contentual context.