Engineering complexity beyond the surface: discerning the viewpoints, the drivers, and the challenges

Abstract

Complexity is often regarded as a “problem” to solve. Instead of attempting to solve complexity, we follow systems engineering practices and switch back to the problem domain, where a major obstacle is the impossibility to universally define complexity. As a workaround, we explored complexity characterization and its existing shortcomings, including: lack of standardization, inconsistent semantics, system-centricity, insufficiently transparent reasoning, and lack of validation. To address these shortcomings, we proposed a compilatory framework to characterize complexity using the Five Ws information-gathering method. The answer to the WHO question proposed four complexity viewpoints; the answer to the WHY question proposed a two-dimensional structure for complexity drivers; and the answer to the WHAT question derived generalized complexity challenges. As a preliminary step to show the potential of the framework to characterize complexity, we used and validated it as a tool to structure general literature related to complexity. In general, our findings suggest that papers with complexity solutions do not frame their research within the complexity problem domain, hindering the contribution evaluation. Through the viewpoints, we identified general research gaps of six solution directions. From the drivers, we noted three observations in the discourse of complexity origins: (1) a system-driven tendency, (2) a preference for concreteness vs. abstraction, and (3) an unclear distinction between origins and effects. Through the challenges’ findings we explored two hypotheses: (1) a system-centric preference; and (2) a solution-oriented vision, both of which were supported by the results (most challenges relate to the system viewpoint and challenges are defined based on solution directions).

1 Introduction

Complexity has been, for too long, the villain of our stories. The widely accepted perception of complexity as an almighty enemy, has led us to blaming it for many of the problems in organizations, without further questioning. However, there are multiple sides to the story. On the one hand, we have experienced an incredible innovation leap in recent years (Tschirner et al. 2014). We have moved from mechanics to mechatronics and finally to intelligent and interconnected systems such as cyber-physical systems (CPS), smart products and systems of systems (SoS) (Bricogne et al. 2016; Maier 1996; Pereira Pessôa and Jauregui Becker 2020). On the other hand, these advancements are not without consequences: complexity has disproportionately and quickly risen in many areas (Tschirner et al. 2014) The mind map of Fig. 1, non-exhaustively summarizes these consequences of complexity, among which we have increased expectations on systems (adaptation, emergence, intelligence, interconnectedness, etc.) and pressure on technologies, organizations, supply chains, processes, and stakeholders and developers.

Fig. 1

Mind map describing innovation needs vs. complexity symptoms. Based on Sheard and Mostashari (2010) and Tschirner et al. (2014)

The complexity issue exists and puts pressure both in industry and research. Therefore, strategies and solutions on how to deal with it have become critical for researchers to investigate and for companies to apply to stay competitive (Friedenthal 2017). From the Systems Engineering point of view, however, it is imperative to be aware of the distinction between problem domain and solution domain (Bonnema et al. 2016). As stated by Bonnema et al. (2016) “when the distinction between problem domain and solution domain is not made, one might fall into the trap of jumping to conclusions or picking the first solution that comes to mind”.

It is a good practice to step regularly back and forth between problem and solution domains because knowledge is generated in both domains (Bonnema et al. 2016). The need for this continuous stepping inspired this paper. We think the focus has been for a long time on the complexity solutions. We aim then to switch back to the problem domain to improve our understanding of complexity, to later evaluate and improve its solutions as well. The reason for this is that we think that we have reached a point where the lack of overview on complexity has started to hinder its management advancement. Based on our experience, it is currently not easy to see trends of evolution and judge the scientific and practical significance of the various proposed solutions to the problem of complexity.

To judge those solutions, we propose to think of them in systems terms. First, to verify the complexity solutions we need to determine whether or not they fulfill the requirements (MITRE Corporation). Second, to validate the solutions, we should asses them against the operational needs in the most realistic environment possible (MITRE Corporation). But do we have a clear understanding of what the requirements are? And what the needs are?

With these questions in mind, we see why the present work is necessary and where our identified research gap, lack of characterization of complexity, comes from. We also found that the related works on complexity still have some shortcomings, as described in Sect. 2.4. This study’s goal is to address both the research gap and the current areas of opportunity. Therefore, we defined our high-level research question as: “How can we support the study of complexity characterization?”. As an answer, we propose a compilatory framework for characterizing complexity in the problem domain, which addresses the shortcomings of previous works by being incorporative rather than alternative. We aim for this framework to support practitioners to characterize and deal with the complexity they experience when engaging in engineering design, its requirements, and its needs.

In this paper, we first review the background of complexity in Sect. 2. There, we identified the lack of characterization of complexity (research gap) as an issue in the problem domain. Also in the background section, we reviewed works studying complexity and characterizing it and we identified their shortcomings (related works’ shortcomings). Section 3 describes the methodology used for validating the framework as a tool to structure general literature related to complexity, which is a preliminary step to show the potential it has for characterizing complexity (additional supplementary material available online). To do so we used a systematic mapping study (SMS). Section 4 proposes a compilatory framework for characterizing complexity by adapting the Five Ws information-gathering method.¹ Section 5 details the execution of the SMS. Finally, Sects. 6, 7, and 8 discuss our findings, draw conclusions, and address future work. The structure of the paper is illustrated in Fig. 2.

Fig. 2

Structure of the paper

2 Background

This section has four objectives. First, we introduce basic concepts. Second, we present the two domains from which we can study complexity. Third, we briefly discuss the issues with the study of complexity, in which we identify a research gap found through reviewing and continuing our previous work (Garza Morales et al. 2019) and our experiences with both industry and research. Finally, we review relevant works studying complexity in the problem domain and identify their shortcomings, several of which we addressed in this paper.

2.1 Basic concepts

Since the present work is in the contexts of systems engineering and engineering design, we consider it appropriate to briefly define basic concepts:

• System: in essence, is a set of interrelated components working together with the common objective of fulfilling some designated need (Blanchard and Blyler 2016). It is often referred to as system under design (SUD). We consider the system to be the primary result of the process.

• Systems engineering process/(engineering) design process: the way of working to develop large and complex systems (Bonnema et al. 2016).

• Developing organization: an entity ultimately responsible for overall leadership in fulfilling system engineering objectives, for which many different organizational groups may be working in a cooperative and integrated manner (Blanchard and Blyler 2016).

• Environment: for this concept we provide two definitions. The first one is with relation to the system under design for which the environment provides the medium in which the system operates (Blanchard and Blyler 2016). The second definition, refers to the environment being the wider context of developing organization, including the users and those more widely affected through lifecycle effects, the market, geo-political circumstances, etc. (Earl et al. 2004). The environment outside the developing organization is outside the scope of the present work.

2.2 Two domains to study complexity

Clarkson and Eckert (2005) mention that designing provides insights into how to respond to complex systems (how to manage, plan and control them). However, it is the overwhelming complexity of many design projects that demands investigation of complexity theory to improve both the resulting designs and the process to create them. As 80% of the manufacturing cost originates in the design process of a system, it is of vital importance that this process flows optimally and that complexity is addressed properly during design (Clark and Fujimoto 1994). The question then becomes, as pointed out by Toepfer and Naumann (2017), whether there is a methodological silver bullet for handling complexity in product development, such as is often promised. In any design, increased complexity is often associated with complications on logistics, planning, and engineering, as well as higher costs and lengthier and more cumbersome processes (Ameri et al. 2008). Therefore, there is a well-accepted notion for complexity to be regarded as a “problem”.

Traditionally, to solve a problem, we as humans must engage in a form of cognitive processing called problem solving. In general, a common pitfall in problem solving is the tendency to jump to conclusions without adequately examining the problem (Bardwell 1991; Bonnema et al. 2016; Cloutier et al. 2015). Already in 1986, the work by Interaction Associates provided a summary of problem-solving pitfalls. They claim that 90% of the problem solving is spent in: (a) solving the wrong problem, (b) stating a problem in a way that it cannot be solved, (c) solving a solution, (d) stating problems too generally, and (e) trying to get agreement on the solution before there is agreement on the problem (Bardwell 1991). We noticed this type of issue in our previous work, as in most of the papers we examined, the problems were examined with the solution in mind, i.e. not adequately defining the problem or even solving a solution (Garza Morales et al. 2019). To avoid such pitfalls, it is crucial to recognize engineering problem solving is made up from two activities: problem definition or framing, and problem solution (or solving) (Downey 2005).

Analogously, Bonnema et al. (2016) distinguish two domains in the field of systems engineering: the problem domain and the solution domain. The first domain then corresponds to the problem framing, while the second one corresponds to problem solving. We propose to apply these two domains to the study of complexity, to consciously avoid running into the problem-solving pitfalls (see Fig. 3).

Fig. 3

The two domains to study complexity: problem domain and solution domain, adapted from Bonnema et al. (2016). They are distinct yet complementary perspectives for the study of complexity

Both domains should be alternated from time to time as they constitute two domains to study complexity. In our experience from previous work, however, we noticed that most papers dealing with complexity focus on the solutions (Garza Morales et al. 2019). In our previous work (Garza Morales et al. 2019), we encountered a large number of papers proposing or extending frameworks, methodologies, languages and tools in systems engineering, all of which belongs to the solution domain. Therefore, we argue that it is necessary to effectively switch and place explicit attention on the problem domain of the study of complexity.

2.3 The issues with the study of complexity in the problem domain

Complexity is universal yet it remains a vague concept. To understand this contrariety, we refer to Israel (2005) who identifies two categories for scientific terms: (a) those with a precise and even formal definition (like mathematical terms) and (b) those drawn from everyday language and which still (if at all possible) need to attain the status of an unequivocal definition (Israel 2005). Israel (2005) points out that the word “complexity” belongs to the second category.

This lack of unified definition we identify as the first issue of the study of complexity in the problem domain. This issue is well noted in literature, where authors identify many definitions depending on the field (Bonnema 2019; Suh 2016). However, it is important to note that we may never find a solution, i.e., we may never have a universal definition of complexity.

A second issue in the problem domain of complexity study, is what we call lack of unified characterization of complexity. Characterization relates to giving details about what something is like, i.e., describing it, and is different than defining it.² Without this unification, the research problems remain isolated in solution groups which hinders us to see the whole scope of the contributions. We ran into this issue while conducting our previous work, where for instance, we read “Keeping a unified view of the system is an issue in model-based systems engineering (MBSE)”, along with similar statements in papers of knowledge-based engineering (KBE) or product-lifecycle management (PLM) (Garza Morales et al. 2019). When we took a higher abstraction perspective, we realized that the papers we had studied (Garza Morales et al. 2019)were related because the problems they define actually characterize parts of the complexity problem. This relation is not apparent at first, due to the varying terminology and reasoning. However, from a higher abstraction we can see complexity as the missing link, from which a unified characterization can help make those relations explicit and facilitate or even encourage collaboration.

We may not reach a unified definition of complexity, but can we not also have a unified characterization of complexity? We find that, unlike the first issue, we might be able to characterize complexity with a well-founded, adaptable, and expandable complexity characterization framework. Therefore, we take the issue of the lack of characterization of complexity as our literature gap for this study.

2.4 Relevant works studying complexity in the problem domain

We present a selected set of studies like this one in the topic of complexity in the context of engineering design and/or systems engineering. It is important to note that the studies we include here discuss the concept of complexity at a high-abstraction level. The reason for this is that there are many studies that deal with complexity directly or indirectly but do so in a more concrete way, i.e., a specific application.

By exploring papers on complexity in the context of engineering design, we found that they mainly focus on three aspects with respect to complexity: (a) propose a solution, (b) measure, (c) characterize (see Table 1). The first two, account for most of the studies (27 out of 39). The goal to characterize complexity (which is the goal of this study) is less frequently found (only in 7 of the 39 works). Some relevant complexity characterization papers are presented in Table 2.

Table 1 Main goals of the papers studying complexity in engineering

Table 2 Relevant works related to characterizing complexity in engineering and/or design

From the contributions presented in Table 2, it is possible to see that the general commonality is the attempt to categorize complexity. However, there is variability in the language as well as different viewpoints, some of which overlap or are contradictory in nature, as stated in SEBoK’s article on complexity.³ For instance, some authors refer to types, dimensions, features, aspects, facets, categories, drivers, metrics, etc. In general, there is no unifying semantics or structure for these concepts; is a type the same as a dimension, do types contain aspects, drivers, etc.? Or the other way around? Additionally, we find variation with the typologies or categories themselves as they are coming from different perspectives (by functional domain, by element, by attribute, etc.). Finally, variation is also present in the perception of the concepts of causes and effects in complexity, i.e., what some authors consider a cause, others refer to as an effect. Although all the categorizations are valuable, the first general shortcoming we identify is the lack of terminology standardization and their inconsistent semantics.

With regards to the drawbacks presented in Table 2, relevant topics are the predominance of system-centricity in the characterization, the insufficiently transparent reasoning, and the lack of validation or practical/industrial application. The main shortcomings found in relevant works are summarized in Fig. 4.

Fig. 4

Main differences found in relevant works, which are identified as shortcomings of complexity characterization studies

3 Methodology

To answer to our main research question, “How can we support the study of complexity characterization?”, this paper proposes a compilatory framework for characterizing complexity in the problem domain. Within the scope of this paper, the framework has been validated as a tool to structure general literature from the engineering design and systems engineering contexts, both of which are strongly related to the complexity field. We believe that this is a valuable first step to preliminarily show the potential of the framework to support the study of complexity characterization.

3.1 Systematic mapping study methodology

To validate the usefulness of the proposed framework to structure literature, we conducted a systematic mapping study (SMS) referring to established guidelines (Kitchenham and Charters 2007; Petersen et al. 2015). We mainly followed the one from Petersen et al. (2015), and were also inspired by useful practices and suggestions from similar studies (Rashid and Anwar 2016; Wolny et al. 2020; Wortmann et al. 2017).

Given our particular topic, it was necessary to adapt our SMS process, which ultimately led us to adapt the third and fourth steps of the methodology presented by Petersen et al. (2015) as described in Table 3.

Table 3 Methodology by Petersen et al. (2015) compared to this study's methodology

Step 1: Definition of research questions. The three questions from the framework (see Table 5) are used.

Step 2: Conducting the search. To avoid using the topic keyword of complexity, which is too generic, we built up on our previous work (Garza Morales et al. 2019) and use the six most relevant categories related to complexity solution approaches:

• 1. Model-based

• 2. Knowledge-based

• 3. Process-based

• 4. Tool-based

• 5. Matrix-based (e.g., DSMs)

• 6. Product (lifecycle)- based

The remaining categories, although related, were more generic and thus, difficult to apply in this study. They described general concepts that relate to solution characteristics, system characteristics, standards, teamwork, etc.

To conduct the search, we selected keywords for each of the six categories (see Table 4). Furthermore, the queries were sought in five relevant research databases: Wiley, IEEE Xplore digital library, ACM digital library, Springer Link Digital library, and Scopus.

Table 4 Selected keywords per identified category

Apart from the main topic keywords, context keywords were selected to reduce the expected several thousand hits. The context keywords reflect the main areas of study namely “engineering design” and “systems engineering”. If this was not sufficient, a second group of context words related to the multidisciplinary/interdisciplinary aspect was used. In addition, to obtain more precise results, we decided to restrict the search string by the following criteria:

• i. Publication period: To find current challenges, we limited to the last 6 years, between 2014–2020.

• ii. Title, abstract and keywords: If possible, the search engines were configured for title, abstract and keywords.

Step 3: Paper screening. The screening of the papers included sub-steps described below:

• i. Remove duplicates per category

• ii. Screen based on inclusion/exclusion criteria:

  • (a) Contextual relevance: discussion of complexity topics in engineering design and/or systems engineering.

  • (b) Relevance for research questions: Screening of the titles, the abstracts and full text to find:

    • Review/experience report: substantiated challenges, limitations, discussions of state of the art or practice.

    • For primary papers: complexity in the problem domain with sufficient quality (has related research and discussion and conclusion sections).

  • (c) Language: English

  • (d) Peer reviewed: criteria for peer-reviewed based on Petersen et al. (2015).

  • (e) Evolving publications: If a paper has been published several times, we used the newer/longer version.

Step 4: Random selection of screened subset. Our SMS is more comprehensive than a purely quantitative SMS. To manage the workload, we considered sufficient to make a random selection. The random selection would be either 50% of the papers or 30 papers per category, whichever results in a lower number.

Step 5 and 6: Keywording using abstracts, introduction, discussion and conclusions and data extraction and mapping process. For the SMS we extract and code the data from the random selection subset. To manage the effort as efficiently as possible we limited the scanning of the papers to the introduction, background, discussion, and conclusion sections. The mapping was conducted using the software, Atlas.Ti version 22.⁴

4 Compilatory Framework for Characterizing Complexity using an Adaptation of the Five Ws Method

As can be seen in Table 2, there already exist multiple proposals to characterize complexity, whose shortcomings we identified in Fig. 4. Addressing the shortcomings with “yet another framework” may seem contradictory, however, we believe it is possible if the proposed framework has two characteristics: (1) it is compilatory in nature, incorporating rather than contradicting existing proposals; and (2) it offers simplicity and semantic consistency.

To satisfy the first characteristic, the concepts selected for the framework (see Table 5) originated from extensive review and mapping of literature about the design phenomenon, design context, and complexity. Regarding, the second characteristic, our framework’s contribution is to structure complexity characterization by applying the information-gathering method, Five Ws, we chose this method for its simplicity and people’s familiarity with it. As an additional advantage, the structured nature of the Five Ws method guides us to appropriately discern the terminology and semantics by means of the questions. By satisfying both characteristics, the complete framework can overcome several of the shortcomings found in previous works (see Sect. 2.4).

Table 5 Five Ws-inspired questions and associated concepts to characterize complexity

Naturally, since we are dealing with a problem at a high-abstraction level, it was necessary to adapt the Five Ws method. For instance, instead of using the what question to define complexity, which we believe has been widely covered already, we will use it to identify its effects (Bonnema 2019; Hick et al. 2019; Johnson 2007; Lindemann et al. 2009b; Mehr and Lüder 2019; Velte et al. 2017). Furthermore, in our case, the questions when and where, are straightforward to answer. According to Johnson (2007), we perceive complexity in any “situation in which a collection of objects are competing for a limited resource—such as food, space, energy, power or wealth”. Such a situation can, fundamentally, happen anytime and anywhere. Thus, as for the when, complexity has always existed; and humans, although in arguable ways, have been studying complex systems for thousands of years.⁵ Similarly, for the where, the problem of complexity exists worldwide and can concern many diverse disciplines, including physics, engineering, computer science, mathematics, anthropology, meteorology, sociology, economics, psychology, medicine and biology (Johnson 2007). We consider these answers sufficient, therefore the questions when and where will not further be addressed.

The relevant questions for our research are shown in Table 5 along with the associated concept, each of which will be described in detail in the following subsections.

4.1 WHO causes complexity?

This question revolves around the essence of the subject. To find the subjects in complexity we refer to Johnson (2007), who defines complexity science as “the study of the phenomena which emerge from a collection of interacting objects.” Thus, finding those interacting objects would answer the who-question in complexity.

To identify those objects, we studied six references describing elements in system (product) design and development contexts. First, in the early 1960’s, Leavitt (1962) proposed a diamond model with four elements (task, structure, people, and technology) to describe organizational change. This model of Leavitt was later adapted and known as the People, Process, Technology (PPT) triad (Smith and Koenig 1998), or people, process, and means (Moser and Wood 2015). Second, in the late 1980’s, the Air Force Logistics Command (AFLC) launched the QP4 (Quality = Product, Process, People, Performance) initiative (Doherty 1990), describing necessary elements for quality improvement. The QP4 initiative went to become the basis for total quality management (TQM), Six Sigma and Lean Manufacturing, eventually resulting in the more generically known people, process and product or 3P model. Third, Earl et al. (2004) described the elements of the design context as system (under design), process, organization of designers, and the user, with the last one being outside of the developing organization. Fourth, Estefan (Estefan 2008) recognizes the both the scope in- and outside the developing organization in his proposal of the process, methods, tools and environment (PMTE) elements, also noting the effects that technology and people have in them. Additionally, Blessing and Chakrabarti’s (2009) description of the design phenomenon offers a more detailed list of elements. They describe design as a complex, multifaceted phenomenon, involving people, a developing product, a process involving a multitude of activities and procedures; a wide variety of knowledge, tools, and methods; an organization, as well as a micro-economic and macro-economic context. Finally, Browning’s (2016) study of the application of design structure matrices (DSM) identifies five domains: product, organization, process, tools, and goals.

We concluded that, for our scope within the developing organization, we have four generalized design context objects: system under development, process, people, and tooling as summarized in Table 6.

Table 6 Mapping of objects identified in references to generalized design context objects

4.1.1 Complexity viewpoints

Piller and Waringer (1999) point out that instead of providing a standardized definition of complexity within the engineering discipline, we can identify a multitude of specific viewpoints. Based on this assertion, we consider that each of the identified generalized objects provides a unique perspective on complexity and, therefore, constitutes a specific complexity viewpoint (see Fig. 5).

Fig. 5

Generalized objects in the design context with corresponding complexity viewpoints

We, therefore, define the complexity viewpoints as follows:

• Social complexity viewpoint: This viewpoint is associated with the social conditions in which the systems are developed (Anderson and Kieliszewski 2017). People have to collaborate along the design process and form a social system that associates them as a team and to the overarching organization (Toepfer and Naumann 2017; Zouari 2015). According to the principle of equivalence social complexity rises as a consequence of system complexity (Naumann 2005; Ropohl 2009). Complexity may rise due to the number of individuals and teams, their interactivity and formality, geographic dispersion, cultural differences, as well as human and organizational limitations (Toepfer and Naumann 2017; Törngren and Sellgren 2018; Wang et al. 2016).

• Process complexity viewpoint: This viewpoint relates to the process that is being followed while designing, which is highly related to complexity. Puhl (1999), for instance, states that controlling complexity stands for the ability to handle the complexity of processes being followed and their effects without jeopardizing their targets. The complexity of the process that is being used to design and develop may relate to its concurrency, heterogeneity, distribution, iteration, flexibility, interconnectivity and information density, among others (Eckert and Stacey 2010; Jakjoud et al. 2016; Lindemann et al. 2009a; Mehr and Lüder 2019; Törngren and Sellgren 2018).

• System complexity viewpoint: This viewpoint is usually associated with the system under design having “a high number of interconnected elements that have a variable status” (Mehr and Lüder 2019). This variation can include quantity, variety and dynamic of elements and their states, their interaction within the system, and their interaction with the environment (Ehrlenspiel and Meerkamm 2017; Lindemann et al. 2009a; Mehr and Lüder 2019). Furthermore, to meet customization demands, there can be multiple instances and variants of a base system (Gerhard 2017).

• Tooling complexity viewpoint: This viewpoint relates to the sophistication of the IT landscape because of the extensive use of highly advanced and specific IT systems required in design (Gerhard 2017). The high sophistication of the IT landscape is caused by the diversity and dynamics of the relationships between project partners, manufacturers, vendors, and suppliers (Gerhard 2017). Complexity rises due to this sophistication as multiple (specialized) tools and databases are needed, dozens of data formats with different semantics are used, and interoperability is not supported (Gerhard 2017).

The complexity viewpoints compile and generalize the essential objects of the design context that had already been identified in literature. These objects essentially answer the framework’s question of “who causes complexity?”. Furthermore, by assigning a viewpoint to each of the identified objects, we propose to use them as one of the dimensions to structure the complexity characterization.

4.1.2 Comparison to relevant complexity characterization works

The proposed complexity viewpoints generalize some of the classifications offered by the authors in Table 2 compiling them, namely the strategic components by Weber (2005), the elements of the design context by Earl et al. (2004), the complexity types by Lindemann et al. (2009a), the socio-political complexity type and the entities proposed by Sheard and Mostashari (2010), (2011) and Sheard (2013), and the complexity types of Elmaraghy et al. (2012).

With these viewpoints, we address mainly two of the shortcomings of previous works reviewed in Sect. 2 the inconsistent semantics, and the predominance of system-centricity in the characterizations. Firstly, in our case, the viewpoints are solely based on the objects and are not mixed with semantically different concepts such as attributes (e.g. behavior, uncertainty, dynamics, etc.) as often done by other complexity characterizations (see for example in Table 2 the aspects by Earl et al. (2004), the four types of complexity by Suh (2005), the five complexity dimensions by Weber (2005), etc.). Secondly, the fact that the viewpoints consider the various objects, explicitly encourages us to think about more than one viewpoint, avoiding (if desired) a system-centric characterization of complexity.

Additionally, we argue that, because we are transparent about where the viewpoints come from, the framework enables the user to add, remove, divide, or merge the viewpoints as needed. We believe this flexibility and transparency encourages practical application. For instance, one can expand the framework to include the system’s user or the external environment (both of which are out of our research’s scope) into the viewpoints.

4.2 WHY does complexity occur?

This question treats the causes of the problem (Why). Understanding the causes enables appropriate complexity management, and to distinguish the subjects from the causes, and the causes from their effects (Mehr and Lüder 2019). While exploring complexity causes is a promising way to gain understanding and obtain potential benefits, there is quite some variety in the ideas and terminology around it (Maurer 2017a, b; Schlick and Demissie 2016; SEBoK n.d.; Sheard 2013). This variety can also be seen in Table 2.

4.2.1 Complexity drivers and a two-dimensional structure to identify and structure them

In this paper, we propose to use the term complexity driver as the way to answer the why-question. This term is already used by other authors (Mehr and Lüder 2019; Velte et al. 2017; Vogel and Lasch 2016). Although we do not aim to give a formal definition, it is possible to see complexity drivers as factors that can originate and influence (increase or decrease) complexity in the design context (for a more detailed definition, the reader is referred to Vogel and Lasch (2016)).

Since each individual factor is a complexity driver, the concept is essentially unlimited (see for instance the extensive list by Vogel and Lasch (2016)); there can be thousands if not millions of complexity drivers, as they are specific to the context, project, time, team, organization, process phase, etc. Due to this, we also proposed as part of our framework a way to identify and structure them. The viewpoints were used as a starting dimension to structure the complexity drivers. However, this was soon found to be not sufficient; a second dimension was needed to structure the large number of complexity drivers.

From the complexity classifications in Table 2 we identified what we refer to as complexity drivers’ attribute groups, which we used as a second structuring dimension. In essence, these groups are complexity classifications which, although related, are not analogous to the complexity viewpoints, as they do not directly correspond to objects in the design context. In our opinion, the attributes relate to the complexity viewpoints by further describing the causes of each of them, i.e., the complexity drivers. For example, the statement, “complexity relates to the number of people in the project”, references the social viewpoint (people) and the word number describes that the complexity driver, which relates belongs to a structural/quantification attribute group.

We identified five attribute groups, as follows:

• Structural/quantification: This group englobes the complexity drivers related to structure, topology, morphology, quantification, hierarchy, connectivity, and interfaces. As seen in Table 2, there is a major tendency to relate the origin of complexity to a form of structure or quantification (Elmaraghy et al. 2012; Fischi et al. 2015; Paetzold 2017).

• Diversity: This attribute is considered as a major determinant for complexity (Elmaraghy et al. 2012; Jones and Anderson 2005; McMahon 2012). The complexity drivers in this group relate to heterogeneity and variety, for example system variants, diverse market demands, variety in features, information, etc. (Elmaraghy et al. 2012).

• Uncertainty: According to Earl et al. (2004), “uncertainty is present in all areas of design and designing (products, processes, users, and organizations)” and based on Suh (2005), “complexity is defined as the measure of uncertainty to achieve […] requirements”. The complexity drivers in this attribute group relate to the lack of knowledge or clarity regarding a complexity viewpoint or another attribute group.

• Dynamics: The complexity definition provided by MIT ESD attributes complexity with a dynamic characteristic (MIT OpenCourseWare 2007). This dynamic characteristic is often associated with complexity drivers related to behavior, entropy, evolution, change, and predictability (Elmaraghy et al. 2012; Fischi et al. 2015). In our framework, we not only consider the complexity drivers related to dynamics in the viewpoint of the system, but also in relation to the other three viewpoints.

• Limitations: In this group we gather other anxieties and pressures that can function as complexity drivers in each viewpoint (Vogelsang et al. 2017).

To gain semantic consistency and provide a structure for the complexity drivers in our framework, we established a two-dimensional matrix. The first dimension (rows) correspond to the complexity viewpoints, while the second dimension are the attribute groups. The two-dimensional matrix is depicted in Fig. 6.

Fig. 6

Our framework's two-dimensional structure to identify and map complexity drivers is based on complexity viewpoints and an attribute group

4.2.2 Comparison to previous works

Most of the reviewed previous works, did not explicitly distinguish the concept of complexity causes and effects but put them under the umbrella of complexity classifications (with the exception, among others, of Mehr and Lüder (2019), Törngren and Sellgren (2018) and Velte et al.(2017)). The ones which did, treated mostly the concept of drivers as background in their proposals for complexity management, putting little emphasis on the reasoning of such classifications. Within the classifications we found, we noted two limitations. Firstly, some offered only a one-dimensional structure, which could be oversimplified. Secondly, the ones which offered two or more dimensions in their structures, usually did not relate those dimensions explicitly [see for example the work of Calvano (2004)].

With the concept of complexity drivers, the proposed framework facilitates the distinction between causes and effects, as the why-question and its answer, the complexity drivers, deal specifically with the causes only. This notion not only helps standardize terminology and reasoning-threads, but also support researchers to distinguish the right problems, making it easier to identify relevant interwoven elements, factors, and effects. Furthermore, our framework provides a two-dimensional structure that relates the concepts of viewpoints as a first and integrative dimension, and either attributes or interactions as a second dimension. With this structure, we overcome the insufficiency of previous structures (being one dimensional or uncoupled multi-dimensional).

4.3 WHAT are the effects of complexity?

In the Five Ws method, this question consists of questioning the essence of the object (WHAT). For our framework, we use this question to investigate the essence of the effects of complexity. According to Earl et al. (2004), the relationships between the objects and hence the viewpoints in design create yet another level of complexity. In our point of view, however, those relationships are not another level of complexity but the origin of the complexity challenges. Many of the surveyed publications, show an interchangeable use between what we consider the concept of complexity drivers and the concept of complexity challenges. The challenges are not the same as the drivers, but they are related by causality: the challenges are the effect of the drivers. For example, if many people must work together in design (complexity driver), a consequence will be more difficulty to align all those people’s understanding of the system (complexity challenge). This distinction is crucial, because it allows us to study and work on the real challenges and at the same time anticipate them given the presence of certain drivers.

4.3.1 Generalized complexity challenges

We identify the interactions among the complexity viewpoints and derive five generalized complexity challenges (see Fig. 7). The five generalized complexity challenges are described below:

Fig. 7

Generalized complexity challenges, found through the relationships of the viewpoints in the design environment

• a) Alignment of the system and the social viewpoints: This challenge we define as fostering common understanding of the system among the people involved (directly or indirectly) in the design, as each of them holds a set of perspectives and mental models of the system in their heads (McDermott et al. 2014). Common understanding of the system might also span towards product engineering and project management, as their support is crucial for there to be the necessary environment to foster common understanding of the system (Tschirner et al. 2015). Finally, the challenge can even encompass not only a system by itself but also within a portfolio and possibly across many concurrent product programs (D’Ambrosio and Soremekun 2017). The challenge of alignment of the system and the social viewpoint means “the necessary [system] information is held by the right stakeholders” (Tschirner et al. 2015). Those stakeholders can be technical or non-technical.

• b) Alignment of the process and the social viewpoints: This challenge deals with the collective understanding of the process(es) among all the people involved (directly or indirectly) in the design. Stacey et al. (2020a) describe this challenge as “participants in design processes need to understand each other’s perspectives and agree on what the process [models] mean”. In summary, this alignment requires the organization, design team and the individual designers to understand the process by which they generate their designs, the manner in which the design process is being performed, and the direction it is progressing (Marchesi and Matt 2016; O’Donovan et al. 2005). In this challenge it is important to note both the macro- and micro-level processes, as both need to be supported. The macro-level describes the generic procedure for the design (e.g., the V-model). The micro-level process supports every specific design phase and individual process steps where individual designers can structure design sub-tasks and proceed and react in unforeseen situations.

• c) Alignment of the system and the process viewpoints: This alignment challenge describes the need for support methods for system design and to control the system’s complexity (Paetzold 2017). This challenge lays in the ‘close interplay between the design structure (system architecture) and the related organization of tasks involved in the design process’ (Braha and Bar-Yam 2007). Some authors, such as Hick et al. (2019), Zheng et al. (2014) and Li et al. (2019), note the importance of this alignment, as the process directs the team’s interactions and if those are not aligned with the system-related interdependencies it can have a negative impact of the system performance. Additionally, when we do not understand how the existing knowledge of the system is represented, conveyed, and transformed through the engineering process, it also difficult to track or improve engineering artifacts or identify possible reuse scenarios (Kathrein et al. 2019). Instances of complexity drivers that originate this challenge relate to the columns 3,4, 5, 6, and 7 from the two-dimensional mapping structure.

• d) Alignment of the social viewpoint (human factors): This challenge encompasses all the factors related to the human nature and behavior. For example, the tendency of the domain experts of systems engineering organizations to focus more on the technical aspects of a system and to often neglect process aspects can be one of the complexity drivers from which this challenge originates (Kathrein et al. 2019). Tangible consequences of this challenge are often perceived as human errors (Garro and Tundis 2015). This challenge requires considering human nature and behavior, i.e. fully understanding the humans using, designing, and managing the processes, systems and the tools, as well as the effect they have (Chami et al. 2018). Instances of complexity drivers from which this challenge originates, relate primarily to the columns 1 and 2 from the two-dimensional mapping structure. However, we must point out that this also includes any effect that the complexity drivers from the other columns may have in terms of human nature and behavior.

• e) Alignment of the tooling viewpoint with the system, the process, and the social viewpoints: This challenge concerns the orchestration of the tools with themselves as well as with all the other viewpoints. We consider the tools as a medium to conduct the work related to the other viewpoints. There are various types of software (tooling) applications: (a) functional applications (to the system viewpoint), (b) management applications (to support the process and the system viewpoint), and communication applications (to support the social viewpoint) (Fonseca et al. 2006). Those three viewpoints introduce demands to the tooling viewpoint. Reciprocally, each tool used in the design environment also affects the other viewpoints. This is felt as a tension when people, processes and even systems continually have to adapt to the tools instead of the tools adapting to the practices of the people (Anderson and Kieliszewski 2017).

4.3.2 Comparison to previous works

One of the advantages of the complexity challenges we propose is that they are generalized and based on the relationships between the viewpoints. In this way, the reasoning is transparent. Furthermore, the adaptability of the framework is maintained because if more viewpoints are added, then it would be reasonable to think that new relationships would emerge and with those new challenges. This gives concreteness to the challenges and exposes the related viewpoints, which at the same time can be related to respective complexity drivers.

Finally, the concept of complexity challenges in the proposed framework further supports the distinction between causes and effects, as this answer to the what question deals specifically with the effects. The integrative concept of the viewpoints together with the generalized challenges can support researchers in distinguishing the right challenges in complexity research, making it easier to identify relevant interwoven elements and drivers, and potentially increasing the quality and practical success of their solutions.

5 Execution of the systematic mapping study (SMS)

The execution of the steps for the SMS is detailed below:

Step 1: Definition of research questions. The three questions from the framework (see Table 5) are used.

Step 2: Conducting the search. We found 5617 papers, which will be subject to the screening process. This paper set was retrieved from the libraries on the 6th of June 2020, therefore any additions to the libraries after this date are excluded from our study.

Step 3: Paper screening. The screening of the papers was done in several sub-steps and after performing the screening process, our result set contained 386 papers as illustrated in Fig. 8.

Fig. 8

SMS methodology execution results from steps 2, 3 and 4

Because the searches are conducted separately, some papers appear in more than one category. Due to that, out of the 386 papers, we had 373 unique titles. These will be referred to as the screened subset throughout the paper.

Step 4: Random selection of screened subset. The final subset and input to the SMS had 135 papers⁶ and is referred to as random selection subset throughout the paper (see Fig. 8). Appendix A presents the list of the 135 references used in the SMS.

Step 5 and 6: Keywording using abstracts, introduction, discussion and conclusions and Data extraction and mapping process. The results of this step are described in the next section.

6 Results

In this section we present the results of the SMS, which was used to validate the framework as a tool to structure general complexity literature. For each of the subsections, there is supplementary material available online via 4TU.ResearchData (available upon publication of the manuscript).

6.1 WHO causes complexity?

For the SMS, we used relevant keywords that exemplify the respective interacting objects in design. We describe each of the viewpoints along with their respective SMS results in the upcoming paragraphs. Furthermore, Table 7 shows the number of papers per solution direction coded with the respective keywords of the complexity viewpoints. The length of the bars is proportional to the total papers per solution direction, expressed by n.

Table 7 Number of papers per solution direction coded with the keywords defined per complexity viewpoint, where the length of the bar is proportional to total papers per solution direction (n)

The social complexity viewpoint was found in all the reviewed papers from the solution directions of knowledge, model, and process, particularly using the keyword designers. A little less so was the keyword organization, although that one was still highly mentioned in the knowledge and product directions. In contrast, the model and tool solution directions were remarkably low compared to the other directions.

The keyword process was found in all the reviewed papers related to the model, DSM, process, and product solution directions. The keywords activity and project were less often found, particularly infrequently in the directions of DSM and tool.

Regarding the system viewpoint, for the DSM solution direction we note a lack of the keyword design knowledge being mentioned, as well as the infrequent use of the discipline keyword. In the knowledge direction, the system keyword is the one with the most limited use. The model direction is the one with the most mentions of keywords related to the system viewpoint, however, the design knowledge keyword is particularly underrepresented. Regarding the process solution direction, again the keyword design knowledge is the most infrequently mentioned. The product solution direction scored notably low in the system viewpoint, with the keywords discipline, system, and design knowledge mentioned only in slightly more than half the papers. Finally, the tool solution direction had particularly low mentions of the keyword design knowledge.

The keyword tool was particularly infrequently used in the DSM solution direction, and in a slightly minor way in the product direction. The rest of the solution directions often refer to the tooling viewpoint.

6.2 WHY does complexity occur?

Regarding the results of the complexity drivers, in Fig. 9 we show the distribution of the found complexity drivers in the two-dimensional mapping structure: complexity viewpoint vs. attribute group. Additionally, Fig. 10a, shows the number of mapped complexity driver references per complexity viewpoint and Fig. 10b depicts the number of mapped complexity driver references per attribute group. Next, we detail the complexity drivers’ findings per attribute group.

Fig. 9

Distribution of the found complexity drivers in the two-dimensional mapping structure: complexity viewpoint vs. attribute group

Fig. 10

a Number of mapped complexity driver references per complexity viewpoint, b number of mapped complexity driver references per attribute group

6.2.1 Complexity drivers related to quantification

This group contained 130 out of the 135 surveyed papers (see Fig. 10b). The complexity drivers related to the system viewpoint were the highest in the mapping. The number and/or size of: systems, subsystems, components, functions, parameters, variants, of constraints, lines of code, disciplines, technologies involved, information sources and models, as well as all interfaces associated with those concepts, constitute the majority of the examples we found (Amorim et al. 2019; Arnould 2018; Biffl et al. 2016; Levy et al. 2019; Li and Li 2018; Liebel et al. 2018; Mordinyi et al. 2016; Pla et al. 2014; Sabou et al. 2016; Schapke et al. 2018; Shani and Broodney 2015; Sukumaran and Chandran 2015; Sztipanovits et al. 2018; Vaneman and Carlson 2019; Zhang 2019).

For the social viewpoint we found slightly more instances referencing the number of individual designers and engineers, compared to the number/size of teams or organizations. This was similar when commenting on the role of the dependencies, interactions, and information flows as complexity drivers. Those drivers were found more frequently referenced to individual designers (found in thirty-nine out of 135 references) than larger forms of organizational units (found in ten out of 135 references).

In terms of process, associations were found with the processes’ number, scale, activities, and phases, as well as with the number of process models, the degree of process concurrency, the number of iterations, the degree of bureaucracy and formalization, and to the number of decisions made during the process.

For the tooling viewpoint, the number and interactions of tools scored the highest, however, other forms of quantification were also found such as the number of data exchange standards and formats, the number of needs the tools must cover and the size/order of the files/models that the tools must manage.

6.2.2 Complexity drivers related to diversity

The complexity drivers related to diversity were the third largest mapped group (see Fig. 10b). Out of the mapped references for diversity, the majority was again found in the system viewpoint. Diversity in terms of discipline relates to abstraction levels, jargon, concepts and perspectives, development times, interfaces, and system structures. Diversity in terms of the system references system views/definitions, the system types and goals, interfaces, requirements, and functions. In terms of data, information and knowledge, diversity relates to abstraction levels, variables, parameters, information types, and structures.

In the social viewpoint, majority of diversity related to the keyword designer (mapped in sixty out of the 135 surveyed papers) in contrast with organization (found in thirty-seven out of the 135 surveyed papers). For the designer, diversity was found in responsibilities and roles; in personality, mentality, attitudes, and moral values; in workforce age; in educational backgrounds; in experience level; in jargon; in time horizons; and in priorities and perspectives, etc. The diversity in organizational structures, in cultures, in strategies, in languages, in location, between management and practitioners, and type of customers, are examples for the keyword organization.

In the processes, the surveyed papers referred to complexity drivers such as diversity in ways of working; in the types and purposes of process models; in the process distribution; the lifecycles and iteration perspectives; in the process phases; in the process standards; and in the intended results of the processes. Diversity complexity drivers related to the project are found in project management styles and strategies, in teams, between projects, and between the project-level and the organizational-level needs.

Finally, in the tooling viewpoint, we found the semantic gaps and overlaps between the databased and tools to be one of the major complexity drivers in terms of diversity. Next to this, we mapped the diversity: in versioning concepts, in infrastructure and enterprise architectures, in the multiplicity of tools, in the tool management strategies, in fidelity, in the internal data structures, and in the data exchange standards.

6.2.3 Complexity drivers related to uncertainty

Uncertainty was the least mapped group of complexity drivers (see Fig. 10b), with most references found in the system viewpoint. Instances of uncertainty of the system related to the use of new technologies or combinations; the fulfillment of customer needs; the system boundaries and external environment; the verification quality and testing capabilities; and to the consequences of trade-offs and design decisions. In terms of data, information and knowledge, uncertainty was associated with the information contained in the artifacts; the boundaries of the information; and the migration and sharing of data and information. For the discipline keyword, uncertainty related to the required functionality or performance, and the ambiguity of the disciplinary boundaries.

Uncertainty in terms of the social viewpoint, had similar number of references for both its keywords. For the organization, uncertainty was related to environmental conditions for organization’s survival, adaptation, and profitability; return of investment of new products and strategies; and the skillsets and required resources. With respect to the designer, uncertainty was associated with knowledge gaps; design risks and design decisions; changing paradigms; and human nature (interactions, misunderstandings, misinterpretations, etc.).

Some of the complexity drivers found for the process keyword uncertainty are (a) ambiguity in the general understanding of the process; uncertainty inherent in process models; (b) uncertainty associated with the risks, innovativeness, (c) creativity of the process; uncertainty in priorities and decisions; (d) uncertainty in process performance; (e) uncertainty due in process trial-and-error approaches and iterations. For the project keyword, most references mentioned uncertainty: in priorities, in logistics, in required resources, and due to project risks.

Finally, for the tooling viewpoint, we only found a few relevant complexity drivers namely the uncertainty in the tools’ performance (in model and simulation exhaustiveness), the uncertainty related to the use or migration of tools, and uncertainty in tool’s appropriateness and adaptation to the users’ needs and processes.

6.2.4 Complexity drivers related to dynamics

For the dynamics complexity driver group, the SMS showed more balance in the number of references found. Examples of dynamics complexity related to the system keyword are: (unforeseen) design changes; behavior and emergence; changes in technologies; dynamics of the demands on the system, the probability of change initiation; and systems scalability and evolvability. With respect to the discipline keyword, dynamics related to discipline paradigms, technologies, and discipline dominance. The dynamic nature of design knowledge, information, and data, as well as their collection, transformation, and exchange, were also mentioned as complexity drivers.

Some of the main examples found for the organization are the dynamics of the organizational and workforce structure; the organizational conventions, strategies, operations, and policies; the culture and internationalization of the working environment; the market, economic and technology trends, and boundary conditions; the relationships with supply chain and customers; and the legislative and regulations. With respect to the designer, dynamics related to changes in position, roles, and responsibilities; group and competence dynamics; (unforeseen) design changes and their effects; as well as individual mentality, paradigms, and culture.

The papers surveyed in the SMS mentioned the changes in the process; (unforeseen) design changes and how the process deals with them; the level of standardization of the process; as well as the dynamic and interconnected nature of the design process as the core complexity drivers. In particular, the paper by Stacey et al. (2020) offers an in-depth view of the reasons for the dynamic nature of the design process.

For the tooling viewpoint, the dynamics complexity driver group had two main sources: firstly, the tools and the infrastructure themselves, and secondly, the dynamics of the other viewpoints and their effect on the tools. From the first, complexity drivers included the dynamics of the information technology, infrastructure and software and the changes in versioning and storage concepts. Regarding the system viewpoint, we have the effects on the tooling of both the system design changes and the requirements. With relation to the social viewpoint, the dynamics of the tools are affected by the needs for inter- and intra-organizational collaboration and user diversity. Finally, related to the process, the dynamic nature of the design also drives dynamic complexity of the tooling.

6.2.5 Complexity drivers related to limitations

In the limitations group, the social viewpoint was the most frequently mapped. The limitation complexity drivers from the keyword organization are related to resources (money, tooling, human, and time); pressures (market, quality, and competitors); change resistance; psychological climate and motivation; strategies and practices; knowledge limitations; workforce age. From the designer limitations found were knowledge, experience, training, individual psychological and motivational climate, individual abilities and skills, individual cognitive capacities, limitations by other organizational stakeholders or legislative barriers, and personal biases and preferences.

Most of the references from system viewpoint related to the knowledge, information, and data keyword. Those limitations relate to the quality of existing information and knowledge; the extraction of tacit/explicit design information, rationale, and semantics; the formalization tension; the consumption needs through the lifecycle; the information overload; and the intangible nature of information and knowledge. The system limitations related to technology and system pressures. In terms of discipline, the limitations were associated with traditions or boundaries, and the tension between the disciplines’ objectives and their optimization.

The limitation instances found for the process were: the intangibility; the difficulty to express and represent; the immaturity of existing methods; the difficulty of practical adoption; pressures of productivity and efficiency; tensions between the various lifecycle stages; genericity and customization tension; the tension between the process creators and followers; the process overload; the appropriateness of the process to a specific purpose; dependency of the process success on resources; the dependency to the organizational structure; and the idealized hierarchy of processes. With respect to the project our findings show limitations related to the resources; the dependency to the organizational structure; and the distance between technical and project management tools.

Finally, for the tooling viewpoint, the limitations group was the largest, which can indicate there are many limitations for this viewpoint. The major tooling limitations found were in terms of functionality, performance; capabilities, and maturity; in the data structures and tooling architectures;; in the exchanges and consistency management; tool vendor restrictions; in the technology infrastructure platforms; tensions in the tools’ genericity vs. specificity; in the tools’ practical application; in the demands of security; tension between technical and human aspects of tools; the tool overload; and dependency on processes and roadmaps, and the quality of tool selection.

6.3 What are the effects complexity?

The effects are considered the generalized complexity challenges and are derived from the relationships among the complexity viewpoints. The findings are described below as well as in Table 8.

Table 8 Number of references found per generalized complexity challenge

6.3.1 Alignment of the system and the social viewpoints

This complexity challenge was by far the most referenced one in the papers checked from the SMS (see Table 8). It was identified in all the solution directions, most notably in the model and knowledge direction. In terms of process, product and tool directions, the challenge was less frequently mentioned, with the tooling one being the least focused on this challenge.

6.3.2 Alignment of the process and the social viewpoints

This challenge was the second most mentioned challenge, although still there was a significant difference in the number of references found compared to the alignment of the system and the social viewpoints. For this challenge, naturally, the process solution direction is predominant. In the other directions, we found far fewer references to this challenge (around half of the ones from process in proportion). Particularly in the tool direction, there were the fewest mentions of this challenge, with only three out of fifteen references.

6.3.3 Alignment of the system and the process viewpoints

This challenge was the least frequently found in the literature. In total, around thirty out of the 135 papers analyzed made any reference to the alignment of the system and the process viewpoints. While about half of the papers of the process direction alluded to this challenge, the other directions, such as knowledge, model, and product, did much less so. Notably, directions such as DSM and tool did not mention this challenge at all.

6.3.4 Management of the social viewpoint (human factors)

This challenge was also not frequently found in the analyzed papers; however, the difference is that it was indeed found in all the solution directions, albeit few times. The process direction mentioned it in about half of the analyzed papers, while the fewest mentions were in the DSM, product, and tooling directions.

6.3.5 Alignment of the tooling viewpoint with the system, the process, and the social viewpoints

This challenge was the third most mentioned in the analyzed literature. As expected, the challenge was well covered in the tool direction. Furthermore, in the model direction we also found this challenge in more than half of the papers, and in the DSM in about half of them. For the other directions, we found it only in about a third (9 out of 30) of the papers.

For each complexity challenge there are one or more complexity management strategies. Those will be studied in a follow-up paper, which will cover the solution domain of the study of complexity.

7 Discussion

According to Ryschkewitsch et al. (2009) one of the characteristics of good systems engineers is that they “continually try to understand the what, why, and how of their jobs”. To live up to this intellectual curiosity, we took a novel approach by looking at complexity in the problem domain. This exercise inspired the present paper and its research question, “How can we support the study of complexity characterization?”. As an answer, we proposed a three-part framework to characterize complexity, by choosing three questions of the Five Ws method. Through the framework we have enriched and reframed the who, why, and what of the complexity problem. Furthermore, the proposed framework addresses the shortcomings of previous works in the problem domain of complexity (see Sect. 2.4), as discussed next.

Firstly, our framework stresses consistent semantics and transparent reasoning using the three chosen W-questions. The consistency and transparent reasoning of the viewpoints comes from deriving them from the interacting objects in design (Who-question). This allows us not to mix them with other types of concepts such as attributes (e.g., behavior, uncertainty, dynamics, etc.), as often done by other researchers (see Fig. 9). For the drivers and challenges, the framework facilitates the distinction between causes and effects, which supports researchers to identify the right problems. Secondly, the multiple viewpoint concept allows our framework to avoid the system-centric complexity characterization, as it explicitly encourages practitioners to think of drivers and challenges in more than one viewpoint. Finally, in terms of validity, the framework has been validated with a systematic mapping study (SMS). Through the SMS, we were able to effectively use the framework to identify and map the viewpoints, drivers, and challenges from six solution directions discussed in a selection of 135 papers. As an additional benefit, the exercise we did to consolidate the currently dispersed literature with our framework can exemplify the potential the framework has to facilitate and structure future research.

7.1 Implications of the findings from the mapping of complexity viewpoints, drivers, and challenges

In general, when surveying the papers selected for the SMS, we encountered statements in each paper about the difficulties in collaboration and complexity. However, complexity is discussed superficially and using varying terminology and reasoning. This lack of clarity and structure makes it difficult to have overview of the field as well as the extent of the contributions, i.e., to know if the right problems (and not only the symptoms) are being solved. Our general expectation was that (some) papers attempting to solve complexity would frame their research within the complexity problem. Our finding is that this is not the case. While researchers attempt to solve complexity with their approaches, their efforts are mostly in specific cases (a lower abstraction level), which although valid and useful, fail to explain how their work contributes to the overall complexity problem (Garza Morales et al. 2023). Next, we detail the findings for each of the three parts of the framework.

Through the complexity viewpoint mapping in the SMS we discovered interesting findings about each of the six solution directions, as described in Sect. 6.1 and summarized in Table 7. One of the findings of this study suggests a disconnection of both DSM and process solution directions towards design knowledge, which we have not yet seen reported before [see for example Browning’s survey (Browning 2016)]. Additionally, findings related to the knowledge solution direction suggest research gaps in project- and system-related applications and dealing with multidisciplinarity. For the model solution direction, there are areas of opportunity to research beyond system and tooling level and towards the organization, project management, and the connection with design knowledge, information, and data. In terms of the process solution, our findings are in line with the tension of generalization and specificity of processes. The proposed solutions are of high-abstraction and do not yet support well the specificity of activities or projects’ details. For the product solution direction, the lower-level implementation of product management processes (e.g., activities and projects) still lacks attention. Finally, the tool solution direction is isolated and there can be opportunities to connect the organization, processes, projects, disciplines, and design knowledge and information.

With regards to the complexity drivers, based on the results presented in Sect. 6.2 and depicted in Figs. 9 and 10, we noted three observations: (1) a tendency towards a system-driven discourse on complexity origins, (2) a preference for concreteness vs. abstraction in the origins of complexity, and (3) an unclear distinction between origins and effects. Firstly, the system-centric discourse on complexity manifested through most complexity drivers being found in the system viewpoint. The fact that most drivers related to limitations were found within the process and organization keywords, further suggests that the solution directions are not yet sufficiently or effectively supporting those areas. Additionally, the low mapping of complexity drivers in the project keyword implies a research gap in the study of the solution directions in terms of projects (or project management). Secondly, with respect to the preference for concreteness, in the SMS we could only map a few references of complexity drivers in the uncertainty attribute group. Furthermore, the high number of mapped complexity drivers corresponding to the attribute group of quantification supports the observation that there is a preference towards the concrete and measurable to understand complexity. Thirdly, the unclear distinction between origins and effects was found in the way the researchers expressed their understanding of complexity: what one author saw as the origin; another saw as an effect.

In terms of the complexity challenges, our findings (see Sect. 6.3) supported two existing hypotheses: (1) a preference for a system-centric complexity challenge identification, similar to the case with the drivers; and (2) a tendency for solution-oriented vision in the research community, as identified in previous work, and the reason to start our SMS with solution directions’ keywords (Garza Morales et al. 2019).

The preference for system-centric complexity challenges is supported by four findings (see Table 8). Firstly, most of the publications we analyzed focus on the challenge of alignment of the system and the social viewpoint, implying a focus to improve the common understanding of the system. Secondly, the alignment of the process and the social viewpoint, and the alignment of the tools with the other viewpoints are often not treated outside their respective solution directions. Possible explanations for isolated attention for the process might be its lack of tangibility, openness to perception, and its frequent association to more management-related topics, all of which make its discussion often not accessible for more technically-oriented people (Kathrein et al. 2019; Vogelsang et al. 2017). Concerning the alignment of the tools, the isolation may partly be explained by the fact that this topic often connects to its IT origins, with a different perspective than that of the designers (Wang et al. 2016). Thirdly, as a challenge, the management of the social viewpoint is not so widely discussed in the papers whereas the social complexity was the second highest mapped. This inconsistency may be due to the technically-driven contexts of systems and engineering design, which recognize the social origins of complexity yet they are rarely the focus of the solutions in the papers (Kathrein et al. 2019). Finally, the alignment of the system and the process viewpoint is the least mentioned complexity challenge, showing an important gap in the study of complexity. A possible explanation for this situation might be that the need for this alignment is not yet clearly identified, as the groups that study the process complexity are normally disconnected from those who study the system complexity, i.e., management-oriented vs. technical-oriented.

The tendency for solution-oriented vision of the research comes from the fact that the analyzed papers often defined their challenges from the perspective of their chosen complexity solution direction (“A challenge for model-based systems engineering decision making”). This can result in two scenarios: (1) they are solving a unique effect of their solution, i.e., a challenge in the solution domain, or (2) they are solving a general complexity challenge but not identifying it as such, making it less accessible to other researchers. Both scenarios foster an obfuscated solution-oriented vision within the research community, limit collaboration, and increase the distance between problem and solution domains. These findings suggest important gaps in the study of complexity and highlight the need to characterize complexity in a sufficiently high-abstraction level, as done through our framework, to reduce the distance between problem and solution domains and to encourage collaboration.

7.2 Tension between problem and solution domains

From the solution domain perspective, it is important to highlight that having sufficient understanding of the problem is not a solution by itself; the ultimate practical goal of complexity study should be to effectively manage it. From the problem domain perspective, however, we cannot get away with oversimplification nor superficiality; we need to have sufficient understanding and awareness of the wickedness of complexity. There is tension between both perspectives and the transition between them should be considered.

We found that the previous complexity characterization works did not explicitly aim at reducing the distance between the problem and the solution domains. Through the conceptualization of our framework, we explicitly recognized this tension between the problem and solution domain in complexity study. The balance in the framework comes from realizing that the study in the problem domain can and should support streamlining to the solution domain. The last part of the problem domain characterization in our framework, i.e., the generalized complexity challenges, consolidate and concretize the understanding of complexity. The generalized challenges are explicitly aimed at facilitating the transition towards the solution domain by being directly connected to the concept of complexity management strategies (see Fig. 11). This topic will be covered in future work.

Fig. 11

The problem domain and solution domain are two perspectives to analyze complexity. The objective of the problem domain is to characterize complexity, while the objective of the solution domain is to manage complexity

7.3 Limitations of our study

A main limitation of our study in the validation of the framework, which we validated as a tool to structure complexity literature, due to the workload constraints. We believe that this is a preliminary step to show its potential for characterizing complexity, however, we have not yet validated this claim.

Further limitations of our study are discussed in terms of methodology, the selection and mapping processes, and the findings. As with many literature-driven studies, our findings are limited by choices in our methodology. Since we include only English-written and recent publications, we missed some papers. Particularly we may have missed German papers, which is the first language of some of the prominently cited authors we found. However, we consider that when the research is mature enough it is also published in English. In terms of the selection of databases, we chose to include five scientific databases to minimize bias in terms of publication avenues.

Regarding the selection process of the papers which were mapped, there are some limitations regarding its internal and external validity. For the internal validity, there are two possible threats: selection and maturation bias. Both were managed by establishing up-front selection criteria. Additionally, for the random selection, used to create a manageable set of papers, we used the random algorithm of MS Excel. For external validity, the use of solution directions as input for the SMS may have affected the analyzed set. This was managed using six diverse directions. The inclusion and exclusion criteria we defined and applied to the best of our abilities, however, the room for interpretation cannot be totally discarded. Additionally, the technical context of the papers may have impacted the results.

For the execution of the mapping process, the manual process is subject to unintentional human errors. Furthermore, experimenter and maturation bias were possible threats to internal validity. We managed these threats by clearly establishing parts of the papers to be analyzed and implementing a coding scheme. To manage the workload, we only analyze specific sections of the papers, possibly missing some information. However, we believe that the randomly selected papers should reflect the position of the authors regarding complexity. For the external validity, we provide the coding scheme which was used to code the papers in Appendix B. Regarding the mapping process, the room for interpretation of the analyzed papers cannot be completely discarded.

Finally, as with many studies in systems engineering and engineering design, there is some difficulty in generalizing the results. We use a literature SMS as a validation for our framework. To enhance the generality of our findings, empirical evidence could be used in the form of case studies. Last, we only focused on the concept and detail development stages in this paper; similar mappings could be conducted on other stages (e.g., supply chain, manufacturing, service, etc.) of the product development process.

8 Conclusions and future work

In the past, it might have been sufficient to treat complexity as an untouchable, and indestructible mountain that we had to go around. However, the current explosion of complexity has reached a point where this approach can no longer assure success in practice. To address this problem, we propose to study complexity as we study systems. Bonnema et al. (2016) distinguish two domains in the study of systems: problem domain and solution domain and note that it is good practice to step regularly back and forth between them. To counteract the predominance of research in the solution domain, this paper switches the complexity conversation to include the problem domain.

This work addresses four shortcomings from previous works. These are: the lack of standardization and the inconsistent semantics in the used terminology; the predominance of system-centricity in the characterization; the insufficiently transparent reasoning; and the lack of validation or practical/industrial application.

One of the main obstacles in the problem domain is the fact that complexity is impossible to universally define. As a workaround, we explore the possibility of characterizing complexity. With this in mind, we defined our research question: “How can we support the study of complexity characterization?”. The presented framework along with the SMS findings so far suggest it is useful for structuring complexity literature, and preliminarily show its potential to characterize complexity. Furthermore, we evidence the feasibility to adapt information-gathering methods such as the Five Ws to structure complexity literature (together with the concepts proposed by the framework), which again shows its potential to also structure the characterization.

When adapting the Five Ws method as a structure, we paid special attention to the order of the questions as our focus was to discern causality. The first part of the framework concerns the question WHO, identifying the interacting objects related to complexity, and providing an integrative basis with the concept of complexity viewpoints. The second and third parts of the framework, establish a clear causality relationship, namely WHY does complexity occur (cause) and WHAT are the effects (effect)? Respectively, the why-question introduces the concept of complexity drivers, and the what question the concept of the complexity challenges.

As an answer to the Who-question, the first part proposes four complexity viewpoints as an answer to unify the discourse found in the relevant work about the types, angles, or perspectives of complexity. To answer the Why-question, in the second part of the framework, our contribution is a structure to map the complexity drivers on two dimensions. The first dimension is the complexity viewpoint it is connected to, and the second dimension is an attribute group that best describes the driver. To synthesize the answer to the WHAT question, we derive the complexity challenges from the interacting objects of design providing concreteness as well as delimitation.

Main findings were obtained regarding each of the three parts of the framework. Through the viewpoints, we identified general research gaps of six solution directions, among which we highlight: (1) the disconnection of both DSM and process solution directions towards design knowledge; (2) the gap in the knowledge solution direction towards project- and system-related applications and dealing with multidisciplinarity; (3) the lack of support for low-abstraction in the process direction; (4) missing lower-level implementation of product management processes (e.g., activities and projects) in the product direction; and (5) the isolation of the tool solution direction which can be connected to the organization, processes, projects, disciplines, and design knowledge and information. From the drivers, we noted three observations in the discourse of complexity origins: (1) a system-driven tendency, (2) a preference for concreteness vs. abstraction, and (3) an unclear distinction between origins and effects. Through the challenges’ findings we explored two hypotheses: (1) a system-centric preference; and (2) a solution-oriented vision, both of which were supported by the results (most challenges relate to the system viewpoint and challenges are defined based on solution directions).

As part of our future work, we plan to pursue four research avenues. First, we would like to connect the present work in the problem domain of complexity to the solution domain. To do that we will streamline the identified generalized complexity challenges and associate them with complexity management strategies as can be seen in Fig. 11. Second, we plan to relate the six solution directions from our previous work to map the complexity management strategies they apply and evaluate their effectiveness based on how they deal with the complexity viewpoints, drivers and challenges (Garza Morales et al. 2019). Third, we plan to particularly pursue the exploration of the challenge “Alignment of the system and process viewpoints” and the associated complexity management strategies, as this was identified as the least researched challenge from our mapping. Finally, as a follow-up to the validation presented in this paper, which evidenced the usability of the framework to structure complexity literature, we aim to conduct empirical research in industrial settings to improve and validate of the usability of the framework to characterize complexity.

Appendix

1.1 A. List of references for SMS

Source ID	References
1	Browning (2016)
2	Holley et al. (2014)
3	Shajahan et al. (2019)
4	Li and Chen (2014)
5	Diagne et al. (2016)
6	Jung et al. (2018)
7	Wang et al. (2018)
8	Habib (2014)
9	Loureiro et al. (2020)
10	Ezzat et al. (2019)
11	Westphal et al. (2015)
12	Arduin et al. (2015)
13	Jupp and Nepal (2014)
14	Bruno et al. (2014)
15	Mordinyi et al. (2016)
16	Chen and Jupp (2018)
17	Boge and Falk (2019)
18	Alexeeva et al. (2016)
19	Chen and Jupp (2019)
20	Kettinger et al. (2015)
21	Liu and Zaraté (2014)
22	Stjepandić et al. (2015)
23	Zhang (2019)
24	Schapke et al. (2018)
25	Hou and Jiao (2020)
26	Li and Li (2018)
27	Senge (2019)
28	Mayr et al. (2019)
29	Zouari (2015)
30	Levy et al. (2019)
31	Hennig et al. (2016)
32	Sabou et al. (2016)
33	Bruno et al. (2019)
34	Al Khatib et al. (2017)
35	Sukumaran and Chandran (2015)
36	Ahlers et al. (2016)
37	McDermott et al. (2014)
38	Rivera et al. (2017)
39	Anderson and Kieliszewski (2017)
40	Toepfer and Naumann (2017)
41	Camba et al. (2014)
42	Vaneman and Carlson (2019)
43	Eigner et al. (2014)
44	Li et al. (2015)
45	Cloutier et al. (2015)
46	Tschirner et al. (2015)
47	Amorim et al. (2019)
48	D’Ambrosio and Soremekun (2017)
49	Shani and Broodney (2015)
50	Garro and Tundis (2015)
51	Zeigler et al. (2019)
52	Nikolaidou et al. (2015)
53	Huang et al. (2017)
54	Vogelsang et al. (2017)
55	Bajaj et al. (2016)
56	Arnould (2018)
57	Pasquinelli et al. (2017)
58	Denil et al. (2017)
59	Schäfer et al. (2016)
60	Madni and Sievers (2017)
61	Leroux et al. (2018)
62	Dumitrescu et al. (2014)
63	(Wolny et al. 2020)
64	(Hick et al. 2019)
65	Berardinelli et al. (2017)
66	Liebel et al. (2018)
67	Albarello and Kim (2014)
68	Huldt and Stenius (2019)
69	Chami et al. (2018)
70	Morris et al. (2016)
71	Zheng et al. (2014)
72	Li et al. (2019)
73	Zheng et al. (2017)
74	Cao et al. (2020)
75	Melville et al. (2016)
76	Hehenberger et al. (2016)
77	Hollauer et al. (2017)
78	Vermaas (2015)
79	Wynn and Clarkson (2018)
80	Kathrein et al. (2019)
81	Pereira Pessôa and Jauregui Becker (2020)
82	Bricogne et al. (2016)
83	Marchesi and Matt (2016)
84	Törngren and Sellgren (2018)
85	Eder (2014)
86	Stacey et al. (2020)
87	Jakjoud et al. (2016)
88	Cicchetti et al. (2019)
89	Curran et al. (2015)
90	Bielefeld et al. (2019)
91	Haskins and Ruud (2017)
92	Pla et al. (2014)
93	Biffl et al. (2016)
94	Weber (2014)
95	Suh (2016)
96	Maier et al. (2014)
97	Mehr and Lüder (2019)
98	Mordecai and Dori (2013)
99	Paetzold (2017)
100	Horvath (2018)
101	Zeng et al. (2014)
102	Deuter et al. (2018)
103	Bitzer et al. (2016)
104	Wang et al. (2016)
105	Gerhard (2017)
106	Behera et al. (2019)
107	Camba et al. (2016)
108	Nosenzo et al. (2014)
109	Wu et al. (2014)
110	Matthiesen et al. (2019)
111	Katzenbach et al. (2015)
112	Huhtala et al. (2014)
113	Rossi et al. (2016)
114	Sharma et al. (2018)
115	Vosgien et al. (2017)
116	Noël and Dori (2016)
117	Koomen (2017)
118	Urban-Galindo and Ripailles (2019)
119	Boton et al. (2016)
120	Weidmann et al. (2017)
121	Leino et al. (2015)
122	Sztipanovits et al. (2018)
123	Ozkaya (2019)
124	Ziegenhagen et al. (2019)
125	Vagliano et al. (2017)
126	Leitner et al. (2016)
127	Asplund and Törngren (2015)
128	Sztipanovits et al. (2014)
129	Macher et al. (2015)
130	Mordiny et al. (2015)
131	(Zolotas et al. 2020)
132	Imran et al. (2015)
133	Amálio et al. (2016)
134	Cole and Dinkel (2016)
135	Larsen et al. (2018)

1.2 B. Literature coding scheme