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).
Similar content being viewed by others
Explore related subjects
Discover the latest articles, news and stories from top researchers in related subjects.Avoid common mistakes on your manuscript.
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.
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.Footnote 1 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.
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).
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.Footnote 2 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.
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.Footnote 3 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.
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.
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.
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.
-
(a)
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.Footnote 4
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).
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.Footnote 5 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.
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).
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.
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:
-
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.
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 papersFootnote 6 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.
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.
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.
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.
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.
Data availability
The datasets generated and/or analyzed during the current study are available in the 4TU Research Database under the following DOIs: 10.4121/21708260, 10.4121/21708263 and 10.4121/21708269.
Notes
Wikipedia—Five Ws: https://en.wikipedia.org/wiki/Five_Ws.
This is a statement from https://en.wikipedia.org/wiki/Complex_system.
Maximum possible was 146 papers. We subtracted eleven multi-category papers. This resulted in a total of 135 papers.
References
(* = part of the SMS literature)
Adcock R, Sillitto H, Sheard S "Complexity" in SEBoK Editorial Board. 2022 The Guide to the Systems Engineering Body of Knowledge (SEBoK), v. 2.7, R.J. Cloutier (Editor in Chief). Hoboken, NJ: The Trustees of the Stevens Institute of Technology. Accessed 25 Sep 2022. www.sebokwiki.org. BKCASE is managed and maintained by the Stevens Institute of Technology Systems Engineering Research Center, the International Council on Systems Engineering, and the Institute of Electrical and Electronics Engineers Systems Council.
*Ahlers D, Mehrpoor M, Kristensen K, Krogstie J (2016) Challenges for information access in multi-disciplinary product design and engineering settings. In: The 10th international conference on digital information management, ICDIM 2015. Institute of Electrical and Electronics Engineers Inc, pp 109–114. https://doi.org/10.1109/ICDIM.2015.7381865
*Al Khatib A, Fleche D, Mahdjoub M, Bluntzer JB, Sagot JC (2017) Preparation of CAD model for collaborative design meetings: proposition of a CAD add-on. In: Advances on mechanics, design engineering and manufacturing, lecture notes in mechanical engineering, pp 861–870. https://doi.org/10.1007/978-3-319-45781-9_86
*Albarello N, Kim H (2014) Application of an MBSE approach for the integration of multidisciplinary design processes. In: Complex systems design and management. Springer International Publishing, pp 85–96. https://doi.org/10.1007/978-3-319-02812-5_7
*Alexeeva Z, Perez-Palacin D, Mirandola R (2016) Design decision documentation: a literature overview. In: Lecture notes in computer science (including subseries lecture notes in artificial intelligence and lecture notes in bioinformatics), vol 9839 LNCS. Springer, pp 84–101. https://doi.org/10.1007/978-3-319-48992-6_6
*Amálio N, Payne R, Cavalcanti A, Woodcock J (2016) Checking sysML models for co-simulation. In: Lecture notes in computer science (including subseries lecture notes in artificial intelligence and lecture notes in bioinformatics), vol 10009 LNCS. Springer, pp 450–465. https://doi.org/10.1007/978-3-319-47846-3_28
Ameri F, Summers JDJD, Mocko GMGM, Porter M (2008) Engineering design complexity: an investigation of methods and measures. Res Eng Des 19(2–3):161–179. https://doi.org/10.1007/s00163-008-0053-2
*Amorim T, Vogelsang A, Pudlitz F, Gersing P, Philipps J (2019) Strategies and best practices for model-based systems engineering adoption in embedded systems industry. In: Proceedings—2019 IEEE/ACM 41st international conference on software engineering: software engineering in practice, ICSE-SEIP 2019. Institute of Electrical and Electronics Engineers Inc., pp 203–212. https://doi.org/10.1109/ICSE-SEIP.2019.00030
*Anderson LC, Kieliszewski CA (2017) A Socio-technical perspective in support of information sharing for diverse teams in today’s workplace. In: Proceedings—2017 IEEE 3rd international conference on collaboration and Internet computing, CIC 2017, vol 2017-Janua. Institute of Electrical and Electronics Engineers Inc., San Jose, CA, pp 416–420. https://doi.org/10.1109/CIC.2017.00059
*Arduin PE, Duigou JL, Abel MH, Eynard B (2015) Knowledge sharing in design based on product lifecycle management system. In: Smart innovation, systems and technologies, vol 35. Springer Science and Business Media Deutschland GmbH, pp 507–517. https://doi.org/10.1007/978-81-322-2229-3_43
*Arnould V (2018) Using model-driven approach for engineering the system engineering system. In: 2018 13th system of systems engineering conference, SoSE 2018. Institute of Electrical and Electronics Engineers Inc., pp 608–614. https://doi.org/10.1109/SYSOSE.2018.8428769
*Asplund F, Törngren M (2015) The discourse on tool integration beyond technology, a literature survey. J Syst Softw 106:117–131. https://doi.org/10.1016/j.jss.2015.04.082
*Bajaj M, Zwemer D, Cole B, Zwemer D (2016) Architecture to geometry—integrating system models with mechanical design. Aiaa Space 2016:1–19. https://doi.org/10.2514/6.2016-5470
Bardwell LV (1991) Problem-framing: a perspective on environmental problem-solving. Environ Manag 15(5):603–612. https://doi.org/10.1007/BF02589620
Behera AK, McKay A, Earl CF, Chau HH, Robinson MA, de Pennington A, Hogg DC (2019) Sharing design definitions across product life cycles. Res Eng Design 30(3):339–361. https://doi.org/10.1007/s00163-018-00306-0
*Berardinelli L, Mazak A, Alt O, Wimmer M, Kappel G (2017) Model-driven systems engineering: principles and application in the CPPS domain. In: Multi-disciplinary engineering for cyber-physical production systems: data models and software solutions for handling complex engineering projects. Springer International Publishing, pp 261–299. https://doi.org/10.1007/978-3-319-56345-9_11
*Bielefeld O, Sizikov V, Schlüter N (2019) Research of the possibilities for using and linking TRIZ methods with systems engineering. In: IFIP advances in information and communication technology, vol 572. Springer, pp 174–186. https://doi.org/10.1007/978-3-030-32497-1_15
*Biffl S, Lüder A, Winkler D (2016) Multi-disciplinary engineering for industrie 4.0: semantic challenges and needs. In: Semantic web technologies for intelligent engineering applications. Springer International Publishing, pp 17–51. https://doi.org/10.1007/978-3-319-41490-4_2
*Bitzer M, Vielhaber M, Kaspar J (2016) Product lifecycle management—how to adapt PLM to support changing product development processes in industry? In: Proceedings of NordDesign, NordDesign 2016, vol 1, pp 360–369. https://www.designsociety.org/publication/39313/Product+Lifecycle+Management+-+How+to+adapt+PLM+to+support+changing+product+development+processes+in+industry%3F. Accessed 25 Sep 2022
Blanchard BS, Blyler JE (2016) Introduction to system engineering. In: Blanchard BS, Blyler JE (eds) System engineering management. John wiley & sons Inc. https://doi.org/10.1002/9781119178798.ch1
Blessing LTM, Chakrabarti A (2009) Introduction. In: DRM, a design research methodology. Springer, London. https://doi.org/10.1007/978-1-84882-587-1_1
*Boge T, Falk K (2019) A3 architecture views—a project management tool? In: 29th annual INCOSE international symposium. Orlando, pp 971–987. https://doi.org/10.1002/j.2334-5837.2019.00647.x
Bonnema GM (2019) A system design reference model—based on design processes and designers’ experience. J Integr Des Process Sci 22(1):39–60. https://doi.org/10.3233/jid-2018-0005
Bonnema GM, Veenvliet KT, Broenink JFJF (2016). Systems design and engineering: facilitating multidisciplinary development projects. CRC Press. https://research.utwente.nl/en/publications/systems-design-and-engineering-facilitating-multidisciplinary-dev. Accessed 25 Sep 2022
*Boton C, Rivest L, Forgues D, Jupp J (2016) Comparing PLM and BIM from the product structure standpoint. In: IFIP advances in information and communication technology, vol 492. Springer New York LLC, pp 443–453. https://doi.org/10.1007/978-3-319-54660-5_40
Braha D, Bar-Yam Y (2007) The statistical mechanics of complex product development: empirical and analytical results. Manag Sci 53(7):1127–1145. https://doi.org/10.1287/mnsc.1060.0617
*Bricogne M, Le Duigou J, Eynard B (2016) Design processes of mechatronic systems. In: Hehenberger P, Bradley D (eds) Mechatronic futures. Springer International Publishing Switzerland, pp. 75–89. https://doi.org/10.1007/978-3-319-32156-1_6
*Browning TR (2016) Design structure matrix extensions and innovations: a survey and new opportunities. IEEE Trans Eng Manag 63(1):27–52. https://doi.org/10.1109/TEM.2015.2491283
*Bruno G, Antonelli D, Korf R, Lentes J, Zimmermann N (2014) Exploitation of a semantic platform to store and reuse PLM knowledge. In: IFIP advances in information and communication technology, vol 438. Springer New York LLC, pp 59–66. https://doi.org/10.1007/978-3-662-44739-0_8
*Bruno G, Traini E, Lombardi F (2019) A Knowledge-Based System for Collecting and Integrating Production Information. In: IFIP advances in information and communication technology, vol 568. Springer New York LLC, pp 163–170. https://doi.org/10.1007/978-3-030-28464-0_15
Calvano CN, John P (2004) Systems engineering in an age of complexity. Syst Eng 7(1):25–34. https://doi.org/10.1002/sys.10054
*Camba JD, Contero M, Salvador-Herranz G, Plumed R (2016) Synchronous communication in PLM environments using annotated CAD models. J Syst Sci Syst Eng 25(2):142–158. https://doi.org/10.1007/s11518-016-5305-5
*Camba J, Contero M, Salvador-herranz G (2014) Implementation challenges of annotated 3D models in collaborative design environments. In: Lecture notes in computer science (including subseries lecture notes in artificial intelligence and lecture notes in bioinformatics), 8683, pp 222–229. https://doi.org/10.1007/978-3-319-10831-5_33
*Cao Y, Liu Y, Ye X, Zhao J, Gao S (2020) Software-physical synergetic design methodology of mechatronic systems based on formal functional models. Res Eng Des 31(2):235–255. https://doi.org/10.1007/s00163-020-00334-9
*Chami M, Aleksandraviciene A, Morkevicius A, Bruel J-M (2018) Towards solving MBSE adoption challenges: the D3 MBSE adoption toolbox. In: 28th annual INCOSE international symposium. Washington, pp 1463–1477
*Chen Y, Jupp J (2018) Model-based systems engineering and through-life information management in complex construction. In: Chiabert P, Bouras A, Noël F, Ríos J (eds) Product lifecycle management to support industry 4.0. PLM 2018. IFIP advances in information and communication technology, vol 540. Springer New York LLC, pp 80–92. https://doi.org/10.1007/978-3-030-01614-2_8
*Chen Y, Jupp J (2019) BIM and through-life information management: a systems engineering perspective. In: Advances in informatics and computing in civil and construction engineering. Springer International Publishing, pp 137–146. https://doi.org/10.1007/978-3-030-00220-6_17
*Cicchetti A, Ciccozzi F, Pierantonio A (2019) Multi-view approaches for software and system modelling: a systematic literature review. Softw Syst Model 18(6):3207–3233. https://doi.org/10.1007/s10270-018-00713-w
Clark KB, Fujimoto T (1994) Product development performance strategy, organization and management in the world auto industry. In: Fujimoto T (ed) Design studies. Harvard Business School Press. https://books.google.com/books/about/Product_Development_Performance.html?hl=es&id=7cCAASTW6IQC. Accessed 25 Sep 2022
Clarkson J, Eckert C (2005) Design process improvement: a review of current practice. In: Clarkson J, Eckert C (eds) Design process improvement a review of current practice. Springer, Cambridge
Cloutier R, Sauser B, Bone M, Taylor A (2015) Transitioning systems thinking to model-based systems engineering: systemigrams to SysML models. IEEE Trans Syst Man Cybern Syst 45(4):662–674. https://doi.org/10.1109/TSMC.2014.2379657
*Cole B, Dinkel K (2016) Multidisciplinary model transformation through simplified intermediate representations. In: IEEE aerospace conference Proceedings, 2016-June. https://doi.org/10.1109/AERO.2016.7500656
*Curran R, Zhao X, Verhagen WJC (2015) Concurrent engineering and integrated aircraft design. In: Concurrent engineering in the 21st century: foundations, developments and challenges. Springer International Publishing, pp 571–605. https://doi.org/10.1007/978-3-319-13776-6_20
*D’Ambrosio J, Soremekun G (2017) Systems engineering challenges and MBSE opportunities for automotive system design. In: 2017 IEEE international conference on systems, man, and cybernetics, SMC 2017 (Vol. 2017-Janua). Institute of Electrical and Electronics Engineers Inc., pp 2075–2080. https://doi.org/10.1109/SMC.2017.8122925
*Denil J, Salay R, Paredis C, Vangheluwe H (2017) Towards agile model-based systems engineering. In: CEUR workshop Proceedings, 2019, pp 424–429
*Deuter A, Otte A, Ebert M, Possel-Dölken F (2018) Developing the requirements of a PLM/ALM integration: an industrial case study. In: Procedia manufacturing, vol 24. Elsevier B.V., pp 107–113 https://doi.org/10.1016/j.promfg.2018.06.020
Diagne S, Coulibaly A, De Bertrand De Beuvron F (2016) Complex product modeling based on a multi-solution eXtended conceptual design semantic matrix for behavioral performance assessment. Comput Ind 75:101–115. https://doi.org/10.1016/j.compind.2015.06.003
Doherty SD (1990) AFLC quality: developing a blueprint for excellence. IEEE Proc Natl Aerosp Electron Conf 3:1329–1331. https://doi.org/10.1109/NAECON.1990.112966
Downey G (2005) Are engineers losing control of technology?: from ‘problem solving’ to ‘problem definition and solution’ in engineering education. Chem Eng Res Des 83(6):583–595. https://doi.org/10.1205/CHERD.05095
Dumitrescu C, Tessier P, Salinesi C, Gérard S, Dauron A, Mazo R (2014) Capturing variability in model based systems engineering. In: Aiguier M, Boulanger F, Krob D, Marchal C (eds) Complex systems design and management. Springer International Publishing, Cham, pp 125–139
Earl C, Eckert C, Johnson J (2004) Complexity models in design. In: International design conference, vol 28. Springer Nature, Dubrivnik. https://doi.org/10.1007/S00163-016-0249-9
Eckert CM, Stacey MK (2010) What is a process model? Reflections on the epistemology of design process models. In: Modelling and management of engineering processes. Springer London, pp 3–14. https://doi.org/10.1007/978-1-84996-199-8_1
*Eder WE (2014) Engineering design: role of theory, models, and methods. In: An anthology of theories and models of design. Springer London, pp 197–217. https://doi.org/10.1007/978-1-4471-6338-1_10
Ehrlenspiel K, Meerkamm H (2017) Integrierte Produktentwicklung: Denkabläufe, Methodeneinsatz, Zusammenarbeit. Carl Hanser Verlag GmbH & Co. KG, München. https://doi.org/10.3139/9783446449084
*Eigner M, Dickopf T, Apostolov H, Schaefer P, Fai\s st K-G, Ke\s sler A, Ke\s sler A (2014) System lifecycle management: initial approach for a sustainable product development process based on methods of model based systems engineering. In: 11th IFIP international conference on product lifecycle management (PLM). Yokohama, pp 287–300. https://doi.org/10.1007/978-3-662-45937-9
Elmaraghy W, Elmaraghy H, Tomiyama T, Monostori L (2012) Complexity in engineering design and manufacturing. CIRP Ann Manuf Technol 61(2):793–814. https://doi.org/10.1016/j.cirp.2012.05.001
Estefan JA (2008) Survey of model-based systems engineering (MBSE) Methodologies. INCOSE MBSE Focus Group 25. Retrieved on: September 25, 2022 from https://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf
*Ezzat O, Medini K, Larsen MSS, Boucher X, Brunoe TD, Nielsen K, Delorme X (2019) A DSM clustering method for product and service modularization. In: IFIP advances in information and communication technology, vol 566. Springer New York LLC, pp 375–382. https://doi.org/10.1007/978-3-030-30000-5_47
Faisandier A, Adcock R “System Validation.” in SEBoK Editorial Board 2022 The Guide to the SystemsEngineering Body of Knowledge (SEBoK), v. 2.7, R.J. Cloutier (Editor in Chief). Hoboken, NJ: The Trustees of theStevens Institute of Technology. Accessed September 25, 2022. www.sebokwiki.org. BKCASE is managed andmaintained by the Stevens Institute of Technology Systems Engineering Research Center, the International Councilon Systems Engineering, and the Institute of Electrical and Electronics Engineers Systems Council
Fischi J, Nilchiani R, Wade J (2015) Dynamic complexity measures for use in complexity-based system design. IEEE Syst J 11(4):2018–2027. https://doi.org/10.1109/JSYST.2015.2468601
Fonseca MJ, Henriques E, Silva N, Cardoso T, Jorge JA (2006) A collaborative CAD conference tool to support mobile engineering. In: Rapid product development (RPD’06). Marinha Grande, Portugal
Friedenthal S (2017) Future directions for product lifecycle management (PLM) and model-based systems engineering (MBSE). SAF Consulting, Reston
*Garro A, Tundis A (2015) Modeling of system properties: research challenges and promising solutions. In: 1st IEEE international symposium on systems engineering, ISSE 2015—Proceedings, pp 324–331. https://doi.org/10.1109/SysEng.2015.7302777
Garza Morales GA, Pereira Pessôa MV, Bonnema GM, Groll MW (2019) A literature survey of multiple discipline integration keywords, based on a process, model, and knowledge classification. In: Systems conference (SysCon), 2019 IEEE international.
Garza Morales GA, Nizamis K, Bonnema GM (2023) Complexity drivers in systems engineering: a scoping review [IN PRESS]. Design, Production and Management Department, University of Twente
*Gerhard D (2017) Product lifecycle management challenges of CPPS. In: Multi-disciplinary engineering for cyber-physical production systems: data models and software solutions for handling complex engineering projects. Springer International Publishing, pp 89–110. https://doi.org/10.1007/978-3-319-56345-9_4
*Habib T (2014) Multidisciplinary product decomposition and analysis based on design structure matrix modeling. In: 7th World conference on mass customization, personalization, and co-creation (MCPC). Springer, Cham, Aalborg, pp 409–423. https://doi.org/10.1007/978-3-319-04271-8_35
*Haskins C, Ruud KS (2017) Systems engineering: making people talk! In: Disciplinary convergence in systems engineering research. Springer International Publishing, pp 1081–1093. https://doi.org/10.1007/978-3-319-62217-0_75
*Hehenberger P, Howard TJ, Torry-Smith J (2016) From mechatronic systems to cyber-physical systems: demands for a new design methodology? In: Mechatronic futures: challenges and solutions for mechatronic systems and their designers. Springer International Publishing, pp 147–163. https://doi.org/10.1007/978-3-319-32156-1_10
*Hennig C, Viehl A, Kämpgen B, Eisenmann H (2016) Ontology-based design of space systems. In: Lecture notes in computer science (including subseries lecture notes in artificial intelligence and lecture notes in bioinformatics), vol 9982 LNCS. Springer, pp 308–324. https://doi.org/10.1007/978-3-319-46547-0_29
Hick H, Bajzek M, Faustmann C (2019) Definition of a system model for model-based development. SN Appl Sci 1(9):1–15. https://doi.org/10.1007/s42452-019-1069-0
*Hollauer C, Becerril L, Kattner N, Weidmann D, Chucholowski N, Lindemann U (2017) Adaptable mechatronic engineering design processes: process reference model and methodology. In: Smart innovation, systems and technologies, vol 65. Springer Science and Business Media Deutschland GmbH, pp 597–607. https://doi.org/10.1007/978-981-10-3518-0_52
Holley V, Jankovic M, Yannou B (2014) Physical interface ontology for management of conflicts and risks in complex systems. Concurr Eng Res Appl 22(2):148–161. https://doi.org/10.1177/1063293X14520760
*Horvath L (2018) New method for enhanced driving of entity generation in RFLP structured product model. In: Proceedings of the 2017 12th IEEE conference on industrial electronics and applications, ICIEA 2017, vol 2018-Febru. Institute of Electrical and Electronics Engineers Inc., pp 541–546. https://doi.org/10.1109/ICIEA.2017.8282903
Hou L, Jiao RJ (2020) Data-informed inverse design by product usage information: a review, framework and outlook. J Intell Manuf. https://doi.org/10.1007/s10845-019-01463-2
*Huang Z, Swalgen S, Davidz H, Murray J (2017) MBSE-assisted FMEA approach—challenges and opportunities. In: Proceedings—annual reliability and maintainability symposium. Institute of Electrical and Electronics Engineers Inc. https://doi.org/10.1109/RAM.2017.7889722
*Huhtala M, Lohtander M, Varis J (2014) Product data management—defining the used terms. IFIP Adv Inf Commun Technol 442:387–396. https://doi.org/10.1007/978-3-662-45937-9_38
*Huldt T, Stenius I (2019) State-of-practice survey of model-based systems engineering. Syst Eng 22:134–145. https://doi.org/10.1002/sys.21466
*Imran S, Buchheit M, Hollunder B, Schreier U (2015) Tool chains in agile ALM environments: a short introduction. In: Lecture notes in computer science (including subseries lecture notes in artificial intelligence and lecture notes in bioinformatics), vol 9416. Springer, pp 371–380. https://doi.org/10.1007/978-3-319-26138-6_40
Israel G (2005) The science of complexity: epistemological problems and perspectives. Sci Context 18(3):479–509. https://doi.org/10.1017/S0269889705000621
*Jakjoud A, Zrikem M, Baron C, Ayadi A (2016) SysPEM: toward a consistent and unified system process engineering metamodel. J Intell Manuf 27(1):149–166. https://doi.org/10.1007/s10845-014-0886-7
Johnson NF (2007) Two’s company, three is complexity: a simple guide to the science of all sciences. Oneworld, Oxford.
Jones BS, Anderson P (2005) Diversity as a determinant of system complexity. Glasgow. http://www.gsa.ac.uk/dds/. Accessed 25 Sep 2022
*Jung S, Asikoglu O, Simpson TW (2018) A method to evaluate direct and indirect design dependencies between components in a product architecture. Res Eng Des 29(4):507–530. https://doi.org/10.1007/s00163-018-0291-x
*Jupp JR, Nepal M (2014) BIM and PLM: comparing and learning from changes to professional practice across sectors. IFIP Adv Inf Commun Technol 442:41–50. https://doi.org/10.1007/978-3-662-45937-9_5
*Kathrein L, Lüder A, Meixner K, Winkler D, Biffl S (2019) Product/ion-aware analysis of collaborative systems engineering processes. In: Security and quality in cyber-physical systems engineering. Springer International Publishing, pp 151–185. https://doi.org/10.1007/978-3-030-25312-7_7
*Katzenbach A, Handschuh S, Dotzauer R, Fröhlich A (2015) Product lifecycle visualization. In: Concurrent engineering in the 21st century: foundations, developments and challenges. Springer International Publishing, pp 287–318. https://doi.org/10.1007/978-3-319-13776-6_11
*Kettinger WJ, Li Y, Davis JM, Kettinger L (2015) The roles of psychological climate, information management capabilities, and IT support on knowledge-sharing: An MOA perspective. Eur J Inf Syst 24(1):59–75. https://doi.org/10.1057/ejis.2013.25
Kitchenham B, Charters S (2007) Guidelines for performing systematic literature reviews in software engineering Version 2.3, Technical report EBSE 2007-001, Keele university and durham university joint report. Retrieved on: September 25, 2022 from https://www.elsevier.com/__data/promis_misc/525444systematicreviewsguide.pdf
*Koomen B (2017) Set based PLM implementation, a modular approach to PLM process knowledge, management and automation. In: IFIP advances in information and communication technology, vol 517. Springer New York LLC, pp 3–12. https://doi.org/10.1007/978-3-319-72905-3_1
*Larsen PG, Fitzgerald J, Woodcock J, Gamble C, Payne R, Pierce K (2018) Features of integrated model-based co-modelling and co-simulation technology. In: Lecture notes in computer science (including subseries lecture notes in artificial intelligence and lecture notes in bioinformatics), vol 10729 LNCS. Springer, pp 377–390. https://doi.org/10.1007/978-3-319-74781-1_26
Leavitt HJ (1962) Applied organization change in industry: structural, technical, and human approaches—cummings center special interest. University of Akron Digital Collections. https://collections.uakron.edu/digital/collection/p15960coll1/id/21949/. Accessed 25 Sep 2022
*Leino SP, Jokinen L, Anttila JP, Pulkkinen A (2015) Case study on engineering change management and digital manufacturing. In: IFIP advances in information and communication technology, vol 467. Springer New York LLC, pp 591–600. https://doi.org/10.1007/978-3-319-33111-9_53
Leitner A, Herbst B, Mathijssen R (2016) Lessons learned from tool integration with OSLC. Commun Comput Inf Sci 639:242–254. https://doi.org/10.1007/978-3-319-46254-7
*Leroux R, Pantel M, Ober I, Bruel J-M (2018) Model-based systems engineering for systems simulation. In: Margaria T, Steffen B (eds) Leveraging applications of formal methods, verification and validation. distributed systems. ISoLA 2018. Lecture notes in computer science. Springer, Cham, pp 429–448. https://doi.org/10.1007/978-3-030-03424-5_29
*Levy M, Hadar I, Aviv I (2019) A requirements engineering methodology for knowledge management solutions: integrating technical and social aspects. Requir Eng 24(4):503–521. https://doi.org/10.1007/s00766-018-0298-x
*Li S, Chen L (2014) Identification of clusters and interfaces for supporting the implementation of change requests. IEEE Trans Eng Manag 61(2):323–335. https://doi.org/10.1109/TEM.2013.2292856
*Li WQ, Li Y (2018) A study on the collaborative management method of product design cycle knowledge. Multimed Tools Appl 77(21):27877–27894. https://doi.org/10.1007/s11042-018-6024-3
*Li S, El-Mounayri H, Zhang W, Schindel B, Sherey J (2015) Implementation of systems engineering model into product lifecycle management platform. IFIP Adv Inf Commun Technol 467:601–608. https://doi.org/10.1007/978-3-319-33111-9
*Li Y, Roy U, Saltz JS (2019) Towards an integrated process model for new product development with data-driven features (NPD 3). Res Eng Des 30(2):271–289. https://doi.org/10.1007/s00163-019-00308-6
*Liebel G, Marko N, Tichy M, Leitner A, Hansson J (2018) Model-based engineering in the embedded systems domain: an industrial survey on the state-of-practice. Softw Syst Model 17(1):91–113. https://doi.org/10.1007/s10270-016-0523-3
Lindemann U, Maurer M, Braun T (2009) Complexity in the context of product design. In: Structural complexity management. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-540-87889-6_2
Lindemann U, Maurer M, Braun T (2009b) Structural complexity management: an approach for the field of product design, 1st edn. https://doi.org/10.1007/978-3-540-87889-6
*Liu S, Zaraté P (2014) Knowledge based decision support systems: a survey on technologies and application domains. In: Lecture notes in business information processing, vol 180 LNBIP. Springer, pp 62–72. https://doi.org/10.1007/978-3-319-07179-4_7
Loureiro GB, Carlos J, Ferreira E, Henrique P, Messerschmidt Z (2020) Design structure network (DSN): a method to make explicit the product design specification process for mass customization. Res Eng Des 31:197–220. https://doi.org/10.1007/s00163-020-00331-y
*Macher G, Armengaud E, Kreiner C (2015) Integration of heterogeneous tools to a seamless automotive toolchain. In: Communications in computer and information science, vol 543. Springer, pp 51–62. https://doi.org/10.1007/978-3-319-24647-5_5
*Madni AM, Sievers M (2017) Model-based systems engineering: motivation, current status, and needed advances. In: Disciplinary convergence in systems engineering research. Springer International Publishing, pp 311–325. https://doi.org/10.1007/978-3-319-62217-0_22
Maier MW (1996) Architecting principles for systems-of-systems. INCOSE Int Symp 6(1):565–573. https://doi.org/10.1002/J.2334-5837.1996.TB02054.X
*Maier JF, Wynn DC, Biedermann W, Lindemann U, Clarkson PJ (2014) Simulating progressive iteration, rework and change propagation to prioritise design tasks. Res Eng Des 25(4):283–307. https://doi.org/10.1007/s00163-014-0174-8
*Marchesi M, Matt DT (2016) Application of axiomatic design to the design of the built environment: a literature review. In: Axiomatic design in large systems. Springer International Publishing, pp 151–174. https://doi.org/10.1007/978-3-319-32388-6_6
Matthiesen S, Grauberger P, Bremer F, Nowoseltschenko K (2019) Product models in embodiment design: an investigation of challenges and opportunities. SN Appl Sci 1(9):1–11. https://doi.org/10.1007/s42452-019-1115-y
Maurer M (2017a) A complexity management framework. In: Complexity management in engineering design—a primer, pp 113–144. https://doi.org/10.1007/978-3-662-53448-9_6
Maurer M (2017b) Introducing complexity in engineering. In: Complexity management in engineering design—a primer. Springer, Berlin, Heidelberg, pp 9–41. https://doi.org/10.1007/978-3-662-53448-9_3
*Mayr A, Meyer A, Schäffer E, Masuch M, von Lindenfels J, Mössinger G, Franke J (2019) Towards a knowledge-based design methodology for managing the complexity in the integrated product and process development of electric motors. In: Advances in production research. Springer International Publishing, pp 112–125. https://doi.org/10.1007/978-3-030-03451-1_12
*McDermott T, Zentner J, Bollweg N (2014) Thinking from the system architecture: a better methodology for capture of collaborative knowledge. In: 2014 international conference on collaboration technologies and systems (CTS). Institute of Electrical and Electronics Engineers (IEEE), Minneapolis, pp 472–473. https://doi.org/10.1109/cts.2014.6867608
McMahon CA (2012) Reflections on diversity in design research. J Eng Des 23:8, 563–576. https://doi.org/10.1080/09544828.2012.676634
*Mehr R, Lüder A (2019) Managing complexity within the engineering of product and production systems. In: Security and quality in cyber-physical systems engineering. Springer International Publishing, pp 57–79. https://doi.org/10.1007/978-3-030-25312-7_3
*Melville C, Yan XT, Gu L (2016) TiV-model-an attempt at breaching the industry adoption barrier for new complex system design methodologies. In: Mechatronic futures: challenges and solutions for mechatronic systems and their designers. Springer International Publishing, pp 41–57. https://doi.org/10.1007/978-3-319-32156-1_4
MIT OpenCourseWare (2007) ESD terms and definitions (version 16). https://ocw.aprende.org/courses/engineering-systems-division/esd-342-network-representations-of-complex-engineering-systems-spring-2010/readings/MITESD_342S10_ESD_terms.pdf. Accessed 25 Sep 2022
*Mordecai Y, Dori D (2013) I5 : a model-based framework for architecting system-of-systems interoperability, interconnectivity, interfacing, integration, and interaction. In: INCOSE international symposium, pp 1234–1255
*Mordiny R, Winkler D, Waltersdorfer F, Scheiber S, Biffl S (2015) Integrating heterogeneous engineering tools and data models: a roadmap for developing engineering system architecture variants. In: Lecture notes in business information processing, vol 200. Springer, pp 89–107. https://doi.org/10.1007/978-3-319-13251-8_6
*Mordinyi R, Serral E, Ekaputra FJ (2016) Semantic data integration: tools and architectures. In: Semantic web technologies for intelligent engineering applications. Springer International Publishing, pp 181–217. https://doi.org/10.1007/978-3-319-41490-4_8
*Morris BA, Harvey D, Robinson KP, Cook SC (2016) Issues in conceptual design and MBSE successes: insights from the model-based conceptual design surveys. In: 26th annual INCOSE international symposium (IS 2016). Edinburgh, pp 269–282. https://doi.org/10.1002/j.2334-5837.2016.00159.x
Moser BR, Wood RT (2015) Complex engineering programs as sociotechnical systems. In: Concurrent engineering in the 21st century: foundations, developments and challenges, pp 51–65. https://doi.org/10.1007/978-3-319-13776-6
Naumann T (2005) Adaptives Systemmanagement Ein Ansatz für die Planung und Steuerung von Produktentwicklungsprozessen. Design. Universität Magdeburg
*Nikolaidou M, Kapos GD, Tsadimas A, Dalakas V, Anagnostopoulos D (2015) Simulating SysML models: overview and challenges. In: 2015 10th system of systems engineering conference, SoSE 2015, pp 328–333. https://doi.org/10.1109/SYSOSE.2015.7151961
*Noël F, Dori D (2016) Towards 3D visualization metaphors for better PLM perception. In: IFIP advances in information and communication technology, vol 467. Springer New York LLC, pp 461–475. https://doi.org/10.1007/978-3-319-33111-9_42
Nosenzo V, Tornincasa S, Bonisoli E, Brino M (2014) Open questions on product lifecycle management (PLM) with CAD/CAE integration. Int J Interact Des Manuf 8(2):91–107. https://doi.org/10.1007/s12008-013-0184-1
O’Donovan B, Eckert C, Clarkson J, Browning TR (2005) Design planning and modelling. In: Design process improvement: a review of current practice. Springer London, pp 60–87. https://doi.org/10.1007/978-1-84628-061-0_3
Ozkaya M (2019) Are the UML modelling tools powerful enough for practitioners? A literature review. IET Softw. https://doi.org/10.1049/iet-sen.2018.5409
*Paetzold K (2017) Product and Systems Engineering/CA* tool chains. In: Multi-disciplinary engineering for cyber-physical production systems: data models and software solutions for handling complex engineering projects. Springer International Publishing, pp 27–62. https://doi.org/10.1007/978-3-319-56345-9_2
*Pasquinelli M, Molina-Tanco L, Reyes-Lecuona A, Cencetti M (2017) Extending the system model. In: Grösser S, Reyes-Lecuona A, Granholm G (eds) Dynamics of long-life assets: from technology adaptation to upgrading the business model, pp 169–189. https://doi.org/10.1007/978-3-319-45438-2
Pereira Pessôa MV, Jauregui Becker JM (2020) Smart design engineering: a literature review of the impact of the 4th industrial revolution on product design and development. Res Eng Des 31(2):175–195. https://doi.org/10.1007/s00163-020-00330-z
Petersen K, Vakkalanka S, Kuzniarz L (2015) Guidelines for conducting systematic mapping studies in software engineering: an update. Inf Softw Technol 64:1–18. https://doi.org/10.1016/j.infsof.2015.03.007
Piller FT, Waringer D (1999) Modularisierung in der Automobilindustrie neue Formen und Prinzipien ; modular sourcing, Plattformkonzept und Fertigungssegmentierung als Mittel des Komplexitätsmanagements. (Shaker, Ed.). Berichte aus der Betriebswirtschaft
*Pla A, Gay P, Meléndez J, López B (2014) Petri net-based process monitoring: a workflow management system for process modelling and monitoring. J Intell Manuf 25(3):539–554. https://doi.org/10.1007/s10845-012-0704-z
Puhl H (1999) Komplexitätsmanagement ein Konzept zur ganzheitlichen Erfassung, Planung und Regelung der Komplexität in Unternehmensprozessen. Kaiserslautern Univ., Lehrstuhl für Fertigungstechnik und Betriebsorganisation. https://www.worldcat.org/title/komplexitatsmanagement-ein-konzept-zur-ganzheitlichen-erfassung-planung-und-regelung-der-komplexitat-in-unternehmensprozessen/oclc/75999055. Accessed 25 Sep 2022
Rashid M, Anwar MW (2016) A systematic investigation of tools in model based system engineering for embedded systems. In: System of systems engineering conference (SoSE), 2016 11th. IEEE, pp 1–6
*Rivera CA, Poza J, Ugalde G, Almandoz G (2017) A knowledge based system architecture to manage and automate the electrical machine design process. In: 2017 IEEE international workshop of electronics, control, measurement, signals and their application to mechatronics (ECMSM), pp 1–6. https://doi.org/10.1109/ECMSM.2017.7945875
Ropohl G (2009) Allgemeine technologie : eine Systemtheorie der technik. Universitätsverlag Karlsruhe
*Rossi M, Cattaneo L, Duigou JL, Fugier-Garrel S, Terzi S, Eynard B (2016) Lean product development and the role of PLM. In: IFIP advances in information and communication technology, vol 492. Springer New York LLC, pp 183–192. https://doi.org/10.1007/978-3-319-54660-5_17
Ryschkewitsch M, Schaible D, Larson W (2009) The art and science of systems engineering. Syst Res Forum 3(2):81–100. https://doi.org/10.1142/S1793966609000080
*Sabou M, Kovalenko, O, Ekaputra FJ, Biffl S (2016) Semantic web solutions in engineering. In: Semantic web technologies for intelligent engineering applications. Springer International Publishing, pp 281–296. https://doi.org/10.1007/978-3-319-41490-4_11
*Schäfer M, Bitsch F, Weißleder S, Wartenberg F (2016) Challenges for MBSE and PLE for legacy product-based system environments. In: Proceedings of the 7th international conference on complex systems design and management, CSD and M Paris 2016. Springer Berlin Heidelberg, pp 3–15. https://doi.org/10.1007/978-3-319-49103-5_1
*Schapke SE, Beetz J, König M, Koch C, Borrmann A (2018) Collaborative data management. In: Building information modeling: technology foundations and industry practice. Springer International Publishing, pp 251–277. https://doi.org/10.1007/978-3-319-92862-3_14
Schlick C, Demissie B (2016) Evaluation of complexity in product development. In: Product development projects. understanding complex systemsunderstanding complex systems, vol 123. Springer, pp 159–214. https://doi.org/10.1007/978-3-319-21717-8_3
Sen Y (2019) Knowledge as a valuable asset of organizations: taxonomy, management and implications. Springer, Cham, pp 29–48. https://doi.org/10.1007/978-3-030-13229-3_2
Senge PM (1990) The fifth discipline. measuring business excellence, vol 1. Currency Doubleday, New York, NY. Retrieved from https://books.google.com/books/about/The_Fifth_Discipline.html?hl=es&id=bVZqAAAAMAAJ. Accessed 25 Sep 2022
*Shajahan CA, Firoz N, Mohammed S, Pramod N, Ashim VR (2019) Managing iterations in product development process using dependency structure matrix. J Phys Conf Ser 1355:12024. https://doi.org/10.1088/1742-6596/1355/1/012024
*Shani U, Broodney H (2015) Reuse in model-based systems engineering. In: 9th annual IEEE international systems conference, SysCon 2015—Proceedings, pp 77–83. https://doi.org/10.1109/SYSCON.2015.7116732
*Sharma S, Segonds F, Maranzana N, Chasset D, Frerebeau V (2018) Towards cloud based collaborative design—analysis in digital PLM environment. In: IFIP advances in information and communication technology, vol 540. Springer New York LLC, pp 261–270. https://doi.org/10.1007/978-3-030-01614-2_24
Sheard SA (2013) Systems engineering complexity in context. INCOSE Int Symp 23(1):1145–1158. https://doi.org/10.1002/J.2334-5837.2013.TB03077.X
Sheard SA, Mostashari A (2010) A complexity typology for systems engineering. In: 20th annual international symposium of the international council on systems engineering, INCOSE 2010, 2, pp 933–945. https://doi.org/10.1002/J.2334-5837.2010.TB01115.X
Sheard SA, Mostashari A (2011) Complexity types: from science to systems engineering. In: 21st annual international symposium of the international council on systems engineering, INCOSE 2011, 1, pp 668–677. https://doi.org/10.1002/J.2334-5837.2011.TB01235.X
Smith D, Koenig L (1998) Modeling and project development. In: Proceedings of the Fifth International Workshop on Simulation for European Space Programmes- SESP '98.
*Stacey M, Eckert C, Hillerbrand R (2020) Process models: plans, predictions, proclamations or prophecies? Res Eng Des 31(1):83–102. https://doi.org/10.1007/s00163-019-00322-8
*Stjepandić J, Verhagen WJC, Liese H, Bermell-Garcia P (2015) Knowledge-based engineering. In: Concurrent engineering in the 21st century: foundations, developments and challenges. Springer International Publishing, pp 255–286. https://doi.org/10.1007/978-3-319-13776-6_10
Suh NP (2005) Complexity in engineering. CIRP Ann 54(2):46–63. https://doi.org/10.1016/S0007-8506(07)60019-5
*Suh NP (2016) Challenges in designing and implementing large systems (overcoming cost overruns and missed project schedules). In: axiomatic design in large systems. Springer International Publishing, pp 273–309. https://doi.org/10.1007/978-3-319-32388-6_11
Sukumaran S, Chandran K (2015) The unspoken requirements—eliciting tacit knowledge as building blocks for knowledge management systems. Lect Notes Bus Inf Process 224:26–40. https://doi.org/10.1007/978-3-319-21009-4_3
*Sztipanovits J, Bapty T, Koutsoukos X, Lattmann Z, Neema S, Jackson E (2018) Model and tool integration platforms for cyber-physical system design. Proc IEEE 106(9):1501–1526. https://doi.org/10.1109/JPROC.2018.2838530
*Sztipanovits J, Bapty T, Neema S, Howard L, Jackson E (2014) OpenMETA: a model- and component-based design tool chain for cyber-physical systems. In: Lecture notes in computer science (including subseries lecture notes in artificial intelligence and lecture notes in bioinformatics), vol 8415 LNCS. Springer, pp 235–248. https://doi.org/10.1007/978-3-642-54848-2_16
*Toepfer F, Naumann T (2017) Towards cross-linked development of highly complex products. In: Proceedings of the 21st international conference on engineering design (ICED17), vol 2. Vancouver: Design Society, pp 279–288 https://www.designsociety.org/publication/39731/Design+heuristics+for+additive+manufacturing. Accessed 25 Sep 2022
*Törngren M, Sellgren U (2018) Complexity challenges in development of cyber-physical systems. In: Lecture notes in computer science (including subseries lecture notes in artificial intelligence and lecture notes in bioinformatics), vol 10760 LNCS. Springer, pp 478–503. https://doi.org/10.1007/978-3-319-95246-8_27
*Tschirner C, Bretz L, Dumitrescu R, Gausemeier J (2015) Applying model-based systems engineering for product engineering management concepts for industrial application. IEEE Syst J. https://doi.org/10.1109/SysEng.2015.7302510
Tschirner C, Kaiser L, Dumitrescu R, Gausemeier J (2014) Collaboration in model-based systems engineering based on application scenarios. In: Proceedings of NordDesign, pp 765–774
*Urban-Galindo J-J, Ripailles S (2019) PLM at GROUPE PSA. In: Product lifecycle management (volume 4): the case studies. Springer, Cham, pp 29–50. https://doi.org/10.1007/978-3-030-16134-7_4
*Vagliano I, Ferretto D, Brusa E, Morisio M, Valacca L (2017) Tool integration in the aerospace domain: a case study. In: Proceedings—international computer software and applications conference, vol 1. IEEE Computer Society, pp 731–736. https://doi.org/10.1109/COMPSAC.2017.241
*Vaneman WK, Carlson R (2019) Model-based systems engineering implementation considerations. In: SysCon 2019—13th annual IEEE international systems conference, Proceedings. Institute of Electrical and Electronics Engineers Inc. https://doi.org/10.1109/SYSCON.2019.8836888
Velte CJ, Wilfahrt A, Müller R, Steinhilper R (2017) Complexity in a life cycle perspective. In: Procedia CIRP 24th CIRP conference on life cycle engineering, vol 61. Elsevier B.V., pp 104–109. https://doi.org/10.1016/J.PROCIR.2016.11.253
*Vermaas PE (2015) Design methodology and engineering design. In: Engineering identities, epistemologies and values. Springer, Cham, pp 147–159. https://doi.org/10.1007/978-3-319-16172-3_8
Vogel W, Lasch R (2016) Complexity drivers in manufacturing companies: a literature review. Logist Res. https://doi.org/10.1007/S12159-016-0152-9
*Vogelsang A, Amorim T, Pudlitz F, Gersing P, Philipps J (2017) Should I stay or should I go?: on forces that drive and prevent mbse adoption in the embedded systems industry. In: Lecture notes in computer science (including subseries lecture notes in artificial intelligence and lecture notes in bioinformatics), 10611 LNCS, pp 182–198. https://doi.org/10.1007/978-3-319-69926-4_14
Vosgien T, Rigger E, Schwarz M, Shea K (2017) A federated enterprise architecture and MBSE modeling framework for integrating design automation into a global PLM approach. IFIP Adv Inf Commun Technol 517:36–48. https://doi.org/10.1007/978-3-319-72905-3
*Wang W, Lünnemann P, Neumeyer S, Hayka H, Stark R (2016) Product development in collaborative networks-an expert view on current challenges and future trends. In: 17th working conference on virtual enterprises (PRO-VE). Porto, pp 302–312. https://doi.org/10.1007/978-3-319-45390-3_26ï
*Wang M, Höfer A, Friedrich H (2018) Conceptual design of suspensions with integrated electric motors on the basis of DSM. In: 20 th international dependency and structure modeling conference, pp 105–114
Weber C (2005) What is “complexity”?. In: Samuel A, Lewis W (eds) Proceedings ICED 05, the 15th international conference on engineering design (p. 293). Melbourne, Australia. https://www.designsociety.org/publication/23103/WHAT+IS+“COMPLEXITY”%3F
*Weber C (2014) Modelling products and product development based on characteristics and properties. In: An anthology of theories and models of design. Springer London, pp 327–352. https://doi.org/10.1007/978-1-4471-6338-1_16
*Weidmann D, Isemann M, Kandlbinder P, Hollauer C, Kattner N, Becerril L, Lindemann U (2017) Product models in mechatronic design: literature analysis on the interdisciplinary character of product models. In: PICMET 2017—Portland international conference on management of engineering and technology: technology management for the interconnected world, Proceedings (Vol. 2017-Janua). Institute of Electrical and Electronics Engineers Inc, pp 1–7. https://doi.org/10.23919/PICMET.2017.8125397
*Westphal I, Freitag M, Thoben KD (2015) Visualization of interactions between product and service lifecycle management. In: IFIP advances in information and communication technology, vol 460. Springer New York LLC, pp 575–582. https://doi.org/10.1007/978-3-319-22759-7_66
*Wolny S, Mazak A, Carpella C, Geist V, Wimmer M (2020) Thirteen years of SysML: a systematic mapping study. Softw Syst Model 19(1):111–169. https://doi.org/10.1007/s10270-019-00735-y
Wortmann A, Combemale B, Barais O (2017). A systematic mapping study on modeling for industry 4.0. In: 2017 ACM/IEEE 20th international conference on model driven engineering languages and systems (MODELS), pp 281–291. https://doi.org/10.1109/MODELS.2017.14
*Wu CC, Ho CF, Hung WH, Kung KH (2014) PLM usage behavior and technology adaptation. In: Communications in computer and information science, vol 473. Springer, pp 76–91. https://doi.org/10.1007/978-3-662-45071-0_7
*Wynn DC, Clarkson PJ (2018) Process models in design and development. Res Eng Des 29(2):161–202. https://doi.org/10.1007/s00163-017-0262-7
*Zeigler BP, Marvin JW, Cadigan JJ (2019) Systems engineering and simulation: converging toward noble causes. In: Proceedings—winter simulation conference, vol 2018-Decem. Institute of Electrical and Electronics Engineers Inc, pp 3742–3752. https://doi.org/10.1109/WSC.2018.8632473
*Zeng F, Li B, Zheng P, Xie SSQ (2014) A modularized generic product model in support of product family modeling in one-of-a-kind production. In: 2014 IEEE international conference on mechatronics and automation, IEEE ICMA 2014. IEEE Computer Society pp 786–791. https://doi.org/10.1109/ICMA.2014.6885797
*Zhang S (2019) Knowledge management environment for collaborative design in product development. In: IFIP advances in information and communication technology, vol 567. Springer New York LLC, pp 475–480. https://doi.org/10.1007/978-3-030-29996-5_55
Zheng C, Bricogne M, Le Duigou J, Eynard B (2014) Survey on mechatronic engineering: a focus on design methods and product models. Adv Eng Inform 28(3):241–257. https://doi.org/10.1016/j.aei.2014.05.003
*Zheng C, Hehenberger P, Le Duigou J, Bricogne M, Eynard B (2017) Multidisciplinary design methodology for mechatronic systems based on interface model. Res Eng Des 28(3):333–356. https://doi.org/10.1007/s00163-016-0243-2
*Ziegenhagen D, Speck A, Pulvermüller E (2019). Using developer-tool-interactions to expand tracing capabilities. In: Proceedings of the 14th international conference on evaluation of novel approaches to software engineering (ENASE 2019), pp 518–525. https://doi.org/10.5220/0007762905180525
*Zolotas A, Hoyos Rodriguez H, Hutchesson S, Sanchez Pina B, Grigg A, Li M, Paige RF (2020) Bridging proprietary modelling and open-source model management tools: the case of PTC Integrity Modeller and Epsilon. Softw Syst Model 19(1):17–38. https://doi.org/10.1007/s10270-019-00732-1
*Zouari A (2015) Knowledge versioning dynamics during the design process in a concurrent engineering environment. Lect Notes Mech Eng 789:11–20. https://doi.org/10.1007/978-3-319-17527-0_2
Acknowledgements
We conducted our research within the Extended Product Lifecycle Management 2.0 project. The research is funded by the European Regional Development Fund (EFRO in Dutch). The authors would like to thank the reviewers for their valuable feedback, which improved the quality of this paper.
Author information
Authors and Affiliations
Contributions
G.A. Garza Morales had the idea for the article, designed and performed the literature search, data analysis, and evaluation, and was the main author of the article. K. Nizamis and G. Maarten Bonnema actively contributed to the study conception, design, and methodology, as well as critically revised the work. All authors read and approved the final manuscript.
Corresponding author
Ethics declarations
Conflict of interest
The authors have no relevant financial or non-financial interests to disclose.
Additional information
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Electronic supplementary material
Below is the link to the electronic supplementary material.
Appendix
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
Rights and permissions
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
About this article
Cite this article
Garza Morales, G.A., Nizamis, K. & Bonnema, G.M. Engineering complexity beyond the surface: discerning the viewpoints, the drivers, and the challenges. Res Eng Design 34, 367–400 (2023). https://doi.org/10.1007/s00163-023-00411-9
Received:
Revised:
Accepted:
Published:
Issue Date:
DOI: https://doi.org/10.1007/s00163-023-00411-9