Coping with System Complexity: Identifying Dichotomic Architectural Alternativesby Gerhard Chroust Certain types of information systems tackled today (so-called 'wicked systems') mean it is necessary to make some initial assumptions about the system architecture before even starting with the actual conceptualization. In general these assumptions define the architecture of the system only on a very high level, but with today's time and money restrictions, it is generally unfeasible or too costly to later change them. These assumptions can be classified into different dimensions using the concept of 'dichotomic architectural alternatives'. Here we discuss implications for the resulting system properties. Today's information systems show a continuous growth in complexity. This growth was identified by Manny M. Lehman back in 1985, who placed systems into certain classifications. These were 'specification systems' (where a complete specification of the system is laid down and must then be fulfilled by the implementation, eg assigning car-plates); 'problem systems' (where only a limited, incomplete knowledge of the problem and the resulting specification is available and the implementation is challenged to find acceptable solutions, eg a traffic simulation program); and 'environment systems' (which have the same properties as problem systems with the added difficulty that their very introduction into the system environment will change the problem, eg control of traffic lights based on simulation with the burden of the uncertainty of drivers' future behaviour). Hermann Kopetz has since added a fourth category - 'wicked problems' - which have the additional property of being large, complex, ill-defined and lacking a clearly identified objective (eg asking for the traffic control to also optimize the travel times of cars). He observes that such a system cannot be specified without some prior concept of its solution. Changing these concepts at a later stage cannot be done without considerable loss of time and effort. As a consequence, ill-conceived projects must either be continued with an inappropriate basic architecture or be abolished. Classification of Architectural Alternatives We intend to isolate and describe such alternatives together with their essential properties, implications, consequences and interactions. In this way, system designers (both newcomers and experts) will be given a clear understanding of the different options available to them, have some support for their intuition, and will therefore make better initial architectural decisions. We classified the alternatives along the following dimensions:
Implication on System Characteristics  The trade-off between module size and number of interconnections, and their impact on system complexity. Another issue is the cross-impact of these alternatives on one another and thus on the aggregated system characteristics. A typical example is the cross-impact of alternatives for choosing a module size: choosing a small module size (granularity) reduces the complexity of the individual modules but at the price of increasing the number of interfaces, which boosts complexity of the whole system. A compromise between the two will give some optimality (see figure). Research in this area clearly holds many challenges. A better understanding of the alternatives and their effects will be of help to both novices and seasoned designers, and will also give a chance to teach in a holistic way some of the basic design decisions that must be made during the initial phase of a new challenging project. Link: Please contact: |
sea.uni-linz.ac.at