by 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 observe that these basic concepts can be classified as 'dichotomic architectural alternatives' along different dimensions, usually providing an either/or alternative. In the real implementation a certain trade-off can usually be achieved, but the basic concept will stay. For example, should a system be centralized or decentralized? In everyday life, the proverb "You can't have your cake and eat it too" can also be seen as an example.
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:
-
Enactment time: WHEN should a foreseen action be performed? (Example: prefetching of variables or just-in-time fetching)
-
Physical Location: where should necessary data and programs be placed? (Example: centralized versus decentralized storage)
-
Granularity: how many/much should be accessed or handled in one step? (Example: choosing a large or a small page size for a paging system)
-
Communication Control/Responsibility: who or what has the responsibility for leading the interaction? (Example: controlling the communication between sender and receiver either by polling or by an interrupt mechanism)
-
Risk expectancy: how probable is an event? (Example: trying to prevent an (improbable) error versus providing detection and repair mechanisms)
-
Optimism versus pessimism: should one prepare for the worst case or for the 'sunshine situation'? (Example: does one expect many or few errors in user inputs?)
-
Reductionistic versus holistic approach: Should one consider only the problem at hand or all its ramifications? (Example: just planning a new motorway technologically or also taking into account environment and commercial implications)
-
Planning horizon: how far into the future should the considerations go (Example: looking for short-term return on investments or for sustainability?)
Implication on System Characteristics
The end-user of a system is not really interested in the architectural choices but rather in the effects of those choices on system properties, such as runtime, size, complexity and development risk. (A more detailed list of system characteristics can be found in ISO/IEC 9126 and in effort estimation methods like COCOMO.) The next step is therefore to identify the implications of the architectural alternatives on these characteristics (for instance, decentralization is less vulnerable to attacks but more complex to implement).
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:
http://www.sea.uni-linz.ac.at
Please contact:
Gerhard Chroust
J. Kepler University Linz / AARIT
Tel: +43 70 2468 8866
E-mail: gc
sea.uni-linz.ac.at
