Multilevel System Architecture

Origin. Mesarovic and Soviet hierarchical systems theory; Glushkov's multi-level ASU (automated control system) architecture.

Mechanism. Complex systems are organized into levels, each with its own time scale, abstraction, and authority. Higher levels set goals and constraints for lower levels; lower levels report status and request decisions they cannot make. The levels are separated by interfaces that hide implementation details. Each level has local autonomy within its constraints, enabling parallel development and operation.

Procedure. Identify natural levels by time scale: strategic (years), tactical (months), operational (days/hours). Or by abstraction: policy, coordination, execution. Define the interface between levels: what information flows up (status, exceptions, requests), what flows down (goals, constraints, resources, decisions). Design each level to be self-contained given its interfaces. The upper level should not need to know how the lower level achieves its results, only whether it does.

Applies to. Enterprise architecture, software architecture, organizational design, any system too complex to design or manage as a single level.

Limitations. Level violations: upper levels reaching into lower-level implementation, or lower levels bypassing constraints. Interface misdesign: too much information flowing up (overload) or too little (blindness). Time scale mismatches: upper levels making decisions too slowly for lower-level needs, or too fast (thrashing). The architecture assumes relatively clean decomposition; highly interconnected systems resist leveling.