Choice and Decision-Making in Engineering and Architecting of Complex Systems

CHOICE AND DECISION-MAKING IN ENGINEERING AND ARCHITECTING OF COMPLEX SYSTEMS

‘Another factor in overruns and delays [in complex acquisitions] is uncertainty, the so-called unknowns and unknown unknowns. Uncertainty is highest during conceptualization, less in design, still less in redesign, and least in upgrade. As with complexity, the higher the level, the more important become experience-based architecting methods’[1]

Introduction

Extensive participative action research into computer-based information systems (CBIS) [2] concluded that not only can requirements not be made fully explicit at the start of a project, they cannot be made fully explicit at all. Soft systems modelling approaches such as the Soft Information Technologies Methodology (SISTeM) used by Atkinson [3] to aid development of CBIS and Iterative and Interactive Strategy Development [4] offer considerable promise as aids to systems architecting. These techniques and systems architecting have potential to fill significant gaps that currently exist in requirements engineering and systems engineering practices. The author of this article reached a similar conclusion to Sutton in respect of Defence communications and information systems, development of decision support systems for the dynamic management of Defence preparedness, and the management of Defence capability.

The Problem

Requirements engineering and management can be problematic for a number of reasons. Complexity of systems and rapid changes in technology are obvious ones. However, the most pervasive reasons are not technical in nature. They are organisational, cultural, or caused by failures in human cognition [5] and linguistic [2,5].

Maier and Rechtin [6] observe that different techniques are required in the engineering of systems at high levels of complexity than at low ones. Purely analytical techniques, powerful for lower levels, can be overwhelmed at higher ones. At higher levels architecting methods, experience-based heuristics, abstraction, and integrated modelling techniques must be called into play [1]. The basic idea behind systems engineering techniques is to simplify problem solving by concentrating on its essentials. Consolidate and simplify the objectives. Stay within the guidelines. Put to one side minor issues likely to be resolved by the resolution of major ones. Discard the nonessentials. Model (abstract) the system at as high a level as possible, then progressively reduce the level of abstraction. In short, Simplify!

Where quantitative models might be used, populating those models built at high levels of abstraction is a problem in itself because data is usually gathered at much lower levels and is not easily aggregated, or if aggregated is meaningless [7,5]. The necessary data is unlikely to be available for analysis of novel problems, or for development of novel systems.

The concept that a complex system can be progressively partitioned into smaller and simpler units—and hence into simpler problems—omits an inherent characteristic of complexity, the interrelationship among units, the strongly coupled nature of complex systems and systemic problems [5,6]. Poor aggregation and partitioning during development can actually increase the complexity, a phenomenon all too apparent in the organisation of work breakdown structures.

This primacy of complexity in system design helps explain why a single ‘optimum’ seldom if ever exists for such systems. There are just too many variables. Variables are a mix of ‘hard’ and ‘soft’ frequently strongly-coupled, there are too many stakeholders, and too many conflicting interests [5,6]. No practical way may exist for obtaining information critical in making the “best” choice among quite different alternatives.

Working Definitions

System. A system is a collection of different things that together produce results unachievable by themselves alone. The value added by systems is in the interrelationships of their elements. These interrelationships produce the emergent properties of systems, where the whole is greater than the sum of the parts.

Systems engineering. Systems engineering is the art and science of creating a product or service, based on phased efforts that involve definition, design, development, production, and maintenance activities. The resulting product or service is functional, reliable, of high quality, and trustworthy, and has been developed within cost and time constraints [8]. Expanded definitions are provided by MIL-STD-499A and MIL-STD-499B.

Requirements engineering involves a structured set of activities which are followed to derive, validate and maintain a systems requirements document. Requirements engineering involves [9]:

Requirements elicitation where requirements are discovered through consultation with stakeholders, from system documents, domain knowledge and use studies (market studies in the commercial world).

Requirements analysis and negotiation during which requirements are analysed in detail and through a process of formal negotiation with stakeholders, decisions are made regarding which requirements are to be accepted.

Requirements validation which involves careful checks of the requirements for consistency and completeness.

Sutton argues that in requirements engineering we need to accommodate the plurality of incommensurable perspectives (users simply do not see requirements the same way), languages and agendas. He argues systems development is a continuous process where users changing their minds is a natural and necessary indication of organisational vitality. Unfortunately this vitality confounds managers of projects where budgets are limited and timely, cost-effective solutions must be delivered.

Systems architecting. Systems architecting involves synthesis and analysis, induction and deduction, and conceptualisation and certification, using guidelines from its art and methods from its science. As a process, it is distinguished from systems engineering in its greater use of heuristic reasoning, lesser use of analytics, closer ties to the client, and particular concern with certification of readiness for use. The foundations of systems architecting are a systems approach, a purpose orientation, a modelling methodology, ultraquality, certification and insight [6].

A number of techniques are available to strengthen the systems engineering processes by making the early conceptualisation activities more robust [5]. Successful application of these techniques requires [5,10]:

• close and continual involvement of stakeholders;
• an appreciation of emergent properties, that is the attribute of systems where the whole is greater than the sum of the parts and where those parts are strongly coupled in a web of interrelationships;
• modelling to support analysis of system dynamics; and
• acceptance that barriers to achieving effective requirements engineering and management can be substantial.

Before techniques such as Iterative and Interactive Strategy Development [4,5], Effects-based Planning [11], SISTeM [3], C4ISR Architectures [12], can be applied in a sensible way, it is necessary to understand the nature of complexity. For a detailed characterisation of complexity and how it impacts upon our problem-solving methods, see McLucas [5].

Both Sutton [2] and McLucas [5] argue that barriers to effective requirements engineering are real and not well understood even by those most closely involved. In essence, systems engineers focus closely on application of systems engineering methodologies, but less on the users and why they think the way they do. Managers do not always understand the systems engineering and systems architecting processes and their roles in those processes.

This article addresses choice and decision-making and the impacts these have on conceptualisation and the formulation of requirements, as well as subsequent management of design, development and in-service management of complex systems. This forms the basis for how requirements engineering, systems engineering, systems architecting and management activities might be improved.

Fundamental Importance of the Conception Phase

Martin[13] reports that in CBIS projects more bugs occur in requirements specification than in coding (56% cf 7%) and bugs in requirements specification are more expensive to correct (82% cf 1%). In more general terms, and in a defence context, cost and efficiency gains in projects accruing from effective conduct of the conception phase are depicted below in Figure 1. Conceptualisation is critically important. The issue here is more than simply stating that the better we are at conceptualisation, the greater the rewards: if conceptualisation is flawed, opportunities leading to favourable outcomes diminish as the project progresses.

Reliance on the Client’s View

Sutton [2] stresses that elicitation and articulation of requirements are problematic for reasons of imprecision in linguistics. Doyle and Ford [14] observe that stakeholders’ views are almost always incomplete, linked to ingrained assumptions, or involve imperfect knowledge. Our reliance on the user’s views may be heaviest when dealing with ‘soft’ variables, those that are not easily quantifiable. In the conceptualisation phase we rely heavily on users’ views until we can formulate more formal ones using systems engineering [8] or systems architecting [6].

User requirements, foundation for all systems engineering activities, are models of systems we aim to deliver, albeit predominantly expressed in textual form. Noting that all models are wrong: some models are better than others [15], care is required to avoid formulations overwhelmingly influenced by any particular stakeholder: conceptual models of systems, that is system requirements, should be the product of collaborative efforts. In a ‘best practice’ situation, users and systems engineers or systems architects are involved in iterative processes building requirements. This involves cycles of conceptualisation, choice, acceptance or rejection of ideas about each aspect of each model, moving repeatedly between lower and higher levels of aggregation, and looking at the system from various perspectives.

Ideas ultimately accepted are translated into statements of requirement, which comprise both ‘hard’ and ‘soft’ variables. As systems become increasingly complex, and when those systems are novel or involve emerging technologies, requirements contain larger numbers of ‘soft’ variables. When it comes to ‘soft’ variables, complete verification and validation, establishing ‘truth’ about them and behaviour produced when they work in concert with other variables, is not possible [16].

Building good requirements involves making repeated adjustments to hypotheses about both ‘hard’ and ‘soft’ systems variables and the relationship between variables regardless of type, noting they can be strongly coupled in a complex web of interrelationships [5]. Highly important, often irreversible, choices are made in the early stages of conceptualisation. Such can be the case even before the existence of a project is formally acknowledged, or project mandate is drafted. Informal pre-project conceptualisation has potential to make or break a project.

Just how good early choices are will dictate the veracity of the requirements and ultimately the capability developed. Some choices will be easier, particularly those which involve ‘hard’ systems aspects such as those dictated by physical laws or physical constraints. Other choices will be more difficult, particularly those which involve ‘soft’ variables. ‘Soft’ systems choices frequently involve the behaviour of ‘man in the loop’: they are dictated by the vagaries of human cognition and behaviour.

Below we look at human cognition, cognitive limitations and failures, and organisational and cultural impacts on choice and decision-making, as they affect systems engineering and systems architecting practices, and requirements conceptualisation, in particular.

Need to Understand Managerial Cognition Before Commencing Conceptualisation

We need to understand managerial cognition, as it applies to users and those involved in systems development, and how we might strengthen it. We need to be able to relate to managers through being able to relate to the ways they think, specifically:

• know the differences between ‘espoused theories’, what they say they think, and ‘theories-in-use’, what they actually think [17];
• be able to identify the nature and limits to managerial ‘domains of action’, what they can actually influence [18];
• understand the influence that individual managers have as ‘gatekeepers’ on access, provision, and interpretation of information;
• understand impediments to both individual and organisational learning created by the ways people think;
• develop skills in eliciting, reading and analysing constituent elements and structure of managerial cognition, that which Laukkanen [18] calls ‘cognitive content’;
• develop skills in analysing and comparing specific cognitive content, views, perspectives, underlying assumptions, or hidden agenda of those involved in decision-making; and
• overall, appreciate what might be done to improve managerial cognition, that is, to enable revision and validation of schemata about capabilities and systems we are trying to develop.

Figure 2^,, depicts relationships between elements comprising managerial cognition.

Human decision-making—bounded rationality and heuristics

Klein et al, [19], Klein [20] and Maier and Rechtin [6], explain that rather than weighing up the utility of alternatives, we use naturalistic decision-making. Naturalistic decision making relies on heuristics, or mental shortcuts, drawn from relevant experiences. Gigerenzer et al [21], conducting research into human decision-making at the Max Planck Institute for Human Development in Berlin, found that:

• heuristics work surprisingly well;
• not only do they allow us to choose between alternative courses of action, they also work when choice doesn’t come with all the options up front;
• people tend to use more calculated reasoning when they can take their time; and
• heuristics come into their own when people are forced to think on their feet.

As will be explained further, below, the dividing line between deliberate decisions, involving careful consideration, and those involving judgement and intuition, where heuristics are invoked, is unclear. So, it is risky to assume requirements ‘models’ are the product of careful ‘weighted’ consideration of all relevant factors. Gigerenzer et al, [21] identify this technique of weighting and considering all relevant factors as Franklin’s Rule, after American philosopher and President, Benjamin Franklin.

‘Gut feeling’ in human decision-making

Heuristics are fundamental to naturalistic decision-making. One familiar form of naturalistic decision making involves ‘gut feeling’, a mix of judgement and intuition where heuristics are invoked and the choice ultimately made cannot be fully explained by the person taking the choice, or making the decision. That decision ‘feels right’. In September 2000, Vice Chief of the Australian Defence Force, Lieutenant General Des Mueller, was being briefed on the use of a decision support tool proffered as an aid to decision-making in Defence capability development. At the end of the briefing, he stated that ultimately all decisions are made on the basis of intuition and judgement. This admission regarding the application of naturalistic decision making accords with observations of decision researchers such as Klein et al, [19], Klein, [20] and Maier and Rechtin, [6].

On the subject of decision making, Major General (retired) Duncan Francis, previously Chief of Materiel-Army commented ‘… decision-making is like building bridges [and we have been building bridges for thousands of years]… if they look right, they probably are.’ Whilst there is considerable science and engineering behind the building of bridges, the same cannot be said about decisions in a requirements engineering context especially where novel, cutting-edge technologies are involved.

Klein [20] argues that heuristics, particularly the recognition heuristic, bounded rationality, and mental simulation of options or a selected strategy play a critical role in decision-making. Klein argues that whilst heuristics are generally associated with decision-making under pressure of time, they are used in deliberate decision-making much more frequently than many decision-makers would admit. Recent research into naturalistic decision making such as that of Klein [20], supports this proposition.

Busy decision-makers who would be expected to take time for considered decisions frequently do not, instead (apparently) relying heavily on the potentially unsubstantiated advice of others, on trust, and invoking their decision heuristics for the final choice [5]. Despite the appearance of time being taken over a decision, many highly important decisions can (apparently) be made on the basis of judgement and intuition. Klein [20] suggests that the extra time available is spent mentally simulating events that might follow implementation of the chosen strategy and developing justification for choices already made.

When decision-makers use heuristics to resolve complex, dynamic issues the risk of error increases. That decision-makers use intuition and judgement when deliberate decision-making would be more appropriate; can be problematic. The issue is when to use which decision-making paradigm.

Cognitive Failure

Klein et al [19], observe that reasoning is ‘schema-driven’ rather than driven by computational algorithm. Even for problems with many novel elements, typical of naturalistic decision making situations, decision-makers use their knowledge to organise the problem, to interpret the situation and to define what information is valuable and relevant to the solution. Some information may be selected or distorted to fit existing schema, a potential source of error [22]. Use of schema also enables speedy assessment, search, selection and interpretation of relevant information. A critical feature of the schema-driven approach is that people create causal models of the situation in their own minds and mentally simulate these.

In complex environments, there is always a risk that flawed schemata, or inappropriate heuristics are applied by decision-makers. Decision-makers, like all humans, can suffer from various forms of cognitive failure, failure to observe accurately and react appropriately to the complex and uncertain world in which they are immersed. Bias is just one form of cognitive failure [23].

Desire to Keep It Simple

Many managers ask for, indeed demand, simplicity. Simplicity is characterised by complexity index [24], C < 5. This might be a system described by a first order differential equation, or containing a single feedback loop, C = 5 corresponds to the upper limit of human capacity to use mental simulation. This is worrying when complex systems might be characterised by 10⁵ < C < 10⁹, many orders of magnitude more complex. A manifestation of this desire to keep it simple can be demands to set the requirements before starting a project, and then not allowing them to be changed. This can make complex acquisitions more difficult rather than less so as might be expected [1].

Human decision-making—belief and learning

Heuristics are not the only devices that inform our decision-making. Kline [24] explains we have the ability to rapidly recall schemata, that is, all the ideas in a person’s head which are used to represent and interact with the world. Complex schemata are learned:

Complex schemata constitute the basis for a doctor in diagnosing illness, for a musician in playing his or her instrument, for an engineer designing a device, and so forth. These more complex schemata are not merely a string of information but, rather, form complex relational networks that are acquired by and only by long experience and usually focused study… all disciplinary knowledge is based on relatively complex, learned schemata. [24]

In our minds, schemata are broken down into chunks. Our working memory can hold about four chunks, or about seven bits (‘bits of information’, not to be confused with digital bits), whilst our long-term memory can hold about 50,000 bits of information for a single subject area, and around 100,000 bits in total. These can be rapidly recalled using the brain’s multiple, parallel processing capability. Dennett [25] hypothesises that parallel processors throw up multiple drafts—that is, possible solutions from our long-term memory—and working memory chooses between them. Gigerenzer’s work suggests that our heuristics are called upon to aid that choice. Dennett explains that the processes of our working memory are serial and relatively slow compared to the recall from our long-term memory. This has important ramifications for the way we go about conceptualisation of complex systems or resolving conflicts in system requirements:

Miller’s 7-Bit-Rule [50] (relating to the number of bits we can hold in our working memory) has been checked and rechecked by many researchers in many areas of mental activity. It is established empirically beyond reasonable doubt. The “7-bit-limitation” on the human working memory, imposed by Miller’s 7-Bit-Rule, is probably the most important single constraint on the human mind regarding how we form sysreps, which are truth assertions we hold and recall when we want to discuss, analyse, think about or write about—a conceptual model [such as a set of requirements] [24].

The relationship between working and long-term memory and schemata may be as depicted by Figure 3 [5].

Schemata are only valuable if they have been developed from valid and relevant experiences.

Dynamic Environments—misperceptions of Dynamic Feedback

Klein [24] suggests decision-makers firstly invoke recognition to determine a problem is typical of something seen before, then, through combination of schemata recalled from long-term memory and cues from the current situation, build mental simulations. This can be an ineffective strategy in systems engineering situations because systems can be very complex, the result of changing the value of one parameter, or one requirement, is a ‘knock-on effect’, an unintended or undesirable change produced by strong coupling to another element elsewhere in the system. Human ability to mentally simulate situations involving systemic feedback, as described, is extremely limited. See ‘Human Cognitive Limitations’, below. Misperceptions of dynamic feedback can only be avoided by dynamic modelling.

Human Decision-making—different Perspectives of the Same Requirement

Stakeholders all have different perspectives on any given situation – one will view a glass of water as half full, whilst another views it as half empty. Kosko [26] observes that this demands a different way of viewing problems, a way that accommodates ‘fuzzy logic’, where there are many shades of grey.

The need to accommodate perspectives of stakeholders was recognised by Vickers [27]. Klein [24] suggests each stakeholder relates to a different set of cues and builds on his or her own situation awareness, or perspective.

Systems of Meaning

Heuristics, schemata and sysreps may be the building blocks of understanding and learning, but they are only part of an individual’s cognisance. An individual’s cognisance fits within systems of meaning. The relationship between cognisance and meaning is depicted diagrammatically at Figure 4. It is described by Flood [28] as follows:

Meaning arises from people’s cognitive processes and the way that, for each person, their cognisance defines their relationship with other people and the world. Cognitive processes might be conceived of in terms of values, norms, ideologies, thought and emotion, coherence and contradiction. A person’s actions and utterances cannot be made sense of without reference to this texture of what they think. Values are intrinsic desires and motivators. Norms underpin what is considered to be normal and acceptable behaviour. Ideologies are sets of ideas about how things should be. Thought and emotion refer to what a person thinks and how they feel about that, as well as the impact that feelings have on what a person thinks. Coherence and contradiction are qualities of ‘validity’ in cognitive processes. All of these things are key in making an adequate interpretation of what a person says and does.

Cognitive processes constitute meaning that may be shared in some way between people and yet remains somehow personal to individuals. Systems of meaning that people employ may coexist and adapt in relative harmony and/or degrees of conflict. That is, systems of meaning may yield cohesion in cultural ways of living and/or tension arising from disagreement, perhaps leading to coalition building and political interaction. Appreciation of what people mean and the temperament of their coexistence are therefore of central interest when seeking ‘agreement’ on improvement strategies.

There are links between cognition, emotion and cognitive behaviour: choices and decisions are rarely made on purely logical and rational bases.

Human Cognitive Limitations

The gap between our cognitive capability and the complexity we face is enormous [24,5]. This is particularly the case where systemic feedback between elements of systems is involved. In essence:

• The concept of feedback is generally not well understood. Feedback manifests itself almost everywhere and our ability to understand it is poor [29].
• Our decision-making is seriously challenged when it comes to complex and dynamic systems where feedback and delay mechanisms exist. Human ability to predict dynamic behaviour of complex systems involving feedback and delay mechanisms, is poor [30,31].
• Feedback dynamics easily elude human intuition and judgement [32,33,34].
• Our perspectives of systems can be based on flawed or erroneous assumptions and schemata [24,35,36].
• Requirements for complex systems are difficult enough for us to address without being further handicapped by analysis which starts from conflicting, hidden or fallacious assumptions [37,38].

Recognition in Conceptualisation of Complex Systems

Recognition is key to harnessing human intellect in dealing with complexity. Klein’s Integrated Version of Recognition-Primed Decision-Model is depicted at Figure 5 [19,20]. This is applicable in situations where the observer is capable of recognising elements of the system and the linkages between them. It cannot be recognised if it has not been seen or experienced previously. Recognition is context dependent, so an important role for systems engineer or systems architect is to help create the context within which systemic relationships can be recognised. Creating experiences in conceptualisation of complex systems behaviour may be done in virtual environments through cycles of dynamic modelling [39] and by a process of rapid prototyping.

Importance of Communications in Decision Cycles

The interdependence of the various activities in decision-making is shown in the Decision Cycle at Figure 6^,. This diagram emphasises the role of effective communication. Mis-communication is possible at four separate points when we navigate the Decision Cycle. Mis-communication may come about for many reasons including:

• errors occur in the transmission process because we are unable to express perfectly, through verbal or non-verbal communication, exactly what we are thinking;
• errors occur in the reception process because we are unable to interpret perfectly what is transmitted, either as verbal or non-verbal communication;
• noise levels being high relative to the signals;
• misuse of language; or
• confusion in the use of terminology.

Effective communication is essential because the decision cycle must be navigated endlessly. Facilitating effective communications at each of the points identified in the Decision Cycle is vital to assuring understanding, and avoiding errors.

Systems of Knowledge-power

Flood [28] describes knowledge-power:

“…the idea that people in positions of power determine what is considered to be valid knowledge and consequently valid action. ‘Systems of knowledge - power’, in which executive decision-makers are central players, militate against the sharing and flow of information”.

How systems of knowledge-power operate in organisations is depicted diagrammatically at Figure 7.

Espejo [41] observes that:

“Organisations are the outcome of ongoing processes in which people negotiate with each other—not necessarily with the same negotiating power—their organisational constructs and thereby constitute their organisations. Indeed, participants generate distinctions of their own, which they use to coordinate their actions, and through recurrent coordination of actions (that is, language) they create a consensual domain of action, or shared reality…”.

Systems of knowledge-power militate against development of shared reality, a shared reality including detailed understanding of, and agreement about, systems requirements, for example.

Discovering Requirements

Discovering requirements incorporates:

A means of fostering dialogue, exploiting semiotics, that is, the use of icons and symbols in verbal and non-verbal communications.

A way of accommodating varying perspectives about the requirements.

Systemicity, that which acknowledges the complex, dynamic behaviour exhibited by systems, or systems-of-systems. We should not attempt to contemplate complete systems. Rather, we must start from a point that acknowledges the nature of both detail and dynamic complexity.

Figure 8^,,, is a concept map which depicts diagrammatically how stakeholders and analysts, working together, might find out about a problem situation, such as development of user requirements for complex systems [5]. The aim here is to foster, through the systematic use of such intellectual devices, the surfacing of assumptions and schemata, and development of exploratory discourse among people who are grappling with the problems of defining the requirements and developing complex systems.

Churchman [43] and Mason and Mitroff [44] identify preferred modes of gathering and processing information generally used by decision-makers. Choice of which intellectual, semiotic devices to use and how to communicate should be informed by client preferences regarding gathering and processing of information. Further, communications must be facilitated in a non-threatening way. Knowledge elicitation, assumption surfacing and testing can be threatening to individuals. These activities demand highly effective communications.

Decision-making and Decision Support—summary

Good systems engineering and systems architecting practices suggest greatest gains accrue from careful attention to requirements engineering, knowledge elicitation and problem conceptualisation during the conception phase. Action research [5] suggests stakeholder involvement from the very outset, and this involvement should continue throughout model building and strategy development. Stakeholder involvement will enhance understanding of the problems and commitment to strategy implementation.

There are many occasions when need to seek out stakeholder views and perspectives, and rely on them. We need to understand when these, and associated ingrained assumptions, might be flawed. Such awareness only comes from an understanding of complexity itself and a working knowledge of human cognition. This means we must be aware of how people use mental shortcuts in both quick and deliberate decision-making, and the difference between the two. It also means we need to understand how various forms of cognitive behaviour may affect choices, decisions and the way stakeholders act.

We need to know how and when prejudice, bias and politics might come into play. Given that these influences exist and come into play from time-to-time, we cannot trivialise problem conceptualisation without risk of basing model building activities on invalid, biased assumptions or inappropriate choices and decisions. Effective requirements engineering, systems engineering and systems architecting must be built on considerations of the way people think and feel, culture, their prior experiences, and their deeply ingrained assumptions. We need to accept this before we can effectively build requirements and successfully develop complex systems.

References

Author

Lieutenant Colonel (Retired) Alan McLucas BE(Hons), MMngtStud, qtc, previously Principal Consultant with Codarra Advanced Systems in Canberra, is a Senior Lecturer at University College, University of New South Wales, Australian Defence Force Academy. His recently completed PhD investigated the application of systems thinking and system dynamics techniques to decision-making in complex dynamic environments. He has extensive experience in strategic decision-making, capability development, military technology, systems engineering, and materiel acquisition.