1. Introduction
Product architecture is the scheme by which the functions of a product are allocated to physical components (Ulrich, Reference Ulrich1995). Architecture decisions are extremely influential in engineering design. They impact not only a firm’s ability to implement changes, produce variety, and increase performance in products but the firm’s management structure as well (Ulrich, Reference Ulrich1995). Many of these impacts are unexpected and often negative (Crawley et al., Reference Crawley, de Weck, Eppinger, Magee, Moses, Seering, Schindall, Wallace and Whitney2004), with market success and failure often reliant on a product’s architectural configuration (Mikkola, Reference Mikkola2007). Research into product architecture and its effects has produced an overwhelming amount of information over decades, with fundamental sources like (Ulrich, Reference Ulrich1995) being cited by over 4,000 other papers. The amount of knowledge can be difficult to fully absorb and use due to its sheer scope and size. This paper introduces a database structure for collecting architectural findings from peer-reviewed sources that can then be rapidly retrieved and visualized in matrix form to make informed early architecture decisions that exploit a wide range of downstream effects.
Architecture decisions are made in the early stages of the innovation process (Ulrich, Reference Ulrich1995), resulting in their effects being felt in every subsequent phase of product development. Some consequences of architecture decisions are known from a designer’s experience or intuition; however, some will be unexpected and are considered unanticipated effects. Some effects occur soon after the decision, while others arise much later when change is difficult and costly. For example, Brusoni et al. (Reference Brusoni, Marengo, Prencipe and Valente2007) describe how in the 1970s, Pratt and Whitney and GE Aircraft produced aircraft engines on a two-shaft architecture desiring design simplicity. Rolls-Royce conversely developed a more modular, three-shaft architecture. As airlines demanded greater thrust capacity to power ever larger aircraft, the two-shaft design quickly reached the limit of its growth potential, requiring these companies to spend time and resources to design a new product family. Meanwhile, Rolls-Royce captured a significant market advantage, becoming the sole supplier of Airbus A340–500/600 engines, as their three-shaft design allowed for more growth capability.
Product architecture decisions made to achieve desired outcomes are called architecture strategies. To effectively construct these strategies, a certain level of knowledge and understanding is required. Experienced designers can often intuitively reduce risks and costs in their designs, but only within the extent of that experience. Because design is often a complex endeavor involving individuals and teams collaborating across organizational boundaries (Reich and Subrahmanian, Reference Reich and Subrahmanian2022), it cannot be assumed or expected that all designers are adequately experienced.
The extensive literature on product architecture can help bridge the gap between a designer’s experience and their current needs. However, the amount and variety of information on product architecture creates a barrier in and of itself especially for new designers. The list of possible papers on specific strategies easily runs into the hundreds. For example, a designer looking to learn more about the use and effects of modular architecture may refer to Ulrich (Reference Ulrich1995) for its impacts on development, or more recent work by Hackl et al. (Reference Hackl, Krause, Otto, Windheim, Moon, Bursac and Lachmayer2020) on the specific economic effects of modularity for a firm. There are also Brusoni et al. (Reference Brusoni, Marengo, Prencipe and Valente2007) who analyze the costs and benefits of using modularity when problem-solving or Farrell and Simpson (Reference Farrell and Simpson2003) who examine considerations for product platform designs revolving around modularity. Additionally, Sosa et al. (Reference Sosa, Eppinger and Rowles2000) compare trade-offs between modular systems and more integral ones, and so forth each paper provides ever more granular insights into different elements of modular architecture, easily overwhelming practitioners with too much information.
At the other end of the spectrum, some architectural strategies have received much less attention. From our initial survey of the literature, only a handful of papers covered the use of custom, carry-over, or commercial-off-the-shelf (COTS) components, such as Clark (Reference Clark1989) and Ulrich and Ellison (Reference Ulrich and Ellison2005). This could reduce the likelihood of a designer finding one of the few papers on such a topic. Both the amount of information available coupled with rarity for particular topics can impede the acquisition of and trust in relevant information.
As part of a method to make cause-and-effect insights gleaned from published findings more accessible for use by designers, this paper introduces the Product Architecture Strategy and Effects (PASE) matrix. A method for aggregating strategies and effects from the literature on product architecture into a structured data set known as the PASE Database is also shown. This builds a digital system enabling visualization of the cause-and-effect relationships in a way that facilitates design decisions, and identifies areas where knowledge is potentially lacking. This method shares similarities with TRIZ (Moehrle, Reference Moehrle2005) because it aids early design decisions based on patterns emerging from the literature. Unlike TRIZ, the PASE method is not centered on conflict resolution. Instead, the PASE method is centered on revealing cause-and-effect relationships related to product architecture decisions.
To present this method, the remainder of this paper is organized as follows: Section 2 discusses the formation and potential use cases for a PASE matrix. Section 3 describes the methods used for gathering the data from the literature and organizing it to form the PASE Database. Section 4 presents a demonstration of a PASE matrix and its potential insights. Finally, Section 5 contains the concluding remarks and discussion of potential future work in this area.
2. Theoretical development: PASE matrix
This section introduces a new design matrix for visualizing relationships between product architecture strategies and their desired and unintended effects. This matrix facilitates the evaluation of these strategies for suitability, and the exploitation or mitigation of their effects on the design.
2.1. PASE matrices and components
A meaningful evaluation and productive selection of architecture strategies during the design process requires knowledge of their associated effects. A PASE matrix visually indicates the relationships that exist between strategies and their effects as identified and documented from the surveyed literature (Ulrich and Seering, Reference Ulrich and Seering1990; Ulrich, Reference Ulrich1995; Ulrich and Ellison, Reference Ulrich and Ellison1999, Reference Ulrich and Ellison2005; Hackl et al., Reference Hackl, Krause, Otto, Windheim, Moon, Bursac and Lachmayer2020; Eppner et al., Reference Eppner, Höfer, Jonschkowski, Martín-Martín, Sieverling, Wall and Brock2018; Brusoni et al., Reference Brusoni, Marengo, Prencipe and Valente2007; Clark, Reference Clark1989; Danese and Filippini, Reference Danese and Filippini2010; Stone and Wood, Reference Stone and Wood2000; Wyatt et al., Reference Wyatt, Wynn, Jarrett and Clarkson2012; Bonvoisin et al., Reference Bonvoisin, Halstenberg, Buchert and Stark2016; Farrell and Simpson, Reference Farrell and Simpson2003; Jiao et al., Reference Jiao, Simpson and Siddique2007; Sosa et al., Reference Sosa, Eppinger and Rowles2000; Kuo et al., Reference Kuo, Huang and Zhang2001). As seen in Figure 1, a PASE matrix is composed of one or more strategies arrayed as rows, and relevant effects listed as columns. The relationships between each strategy and effect, if present, are indicated with an “X” where the respective row and column intersect. The matrix format enables designers to evaluate product architecture strategies, determine the implications of those strategies and then select the strategies that are most desirable for use in their design project.
Example of effect-driven PASE matrix with anticipated and unanticipated strategies and effects.
In order to build a PASE matrix, an existing database of strategies, effects and their relationships is required. Our initial review of the literature revealed more than two dozen strategies and over 200 effects. These were used to construct the digital PASE Database, which was in turn employed to form the PASE matrices found in the remainder of this paper. Because the database contains several hundred relationships, a graphical interface was developed to interact with it and to automatically construct PASE matrices based on user selections. This interface is known as the PASE Matrix Generator and can be accessed through the following URL: https://www.design.byu.edu/resources/pasematrix. The rational tables used to construct the database are also available for download at this site.
When constructing a PASE matrix, either an effects-driven approach or a strategy-driven approach may be used. Depending on the approach, an initial selection of either one or more effects, or strategies with relevance to the design is made from a list of those available in the PASE Database. As depicted in Figure 1, this selection is referred to as either the effects or strategies of interest and constitutes the starting point for constructing the matrix. The strategies will be listed as rows, and effects as columns. To complete the matrix, either related effects columns are added to a selection of strategies of interest rows, or rows with strategies of interest will be added to an initial selection of effects of interest columns. In the second example, related effects columns for the strategies of interest will then be added to the right of the original effects of interest.
Some of the strategies and effects pulled from the database by the matrix generator may be unanticipated by the designer. This is represented in Figure 1 by the blue (solid) and orange (small dashed) boxes. These strategies and related effects that were not expected are referred to as unanticipated strategies and unanticipated effects. An example of the strategies and effects that may have been anticipated is shown in the green (large dashed) box. The exact boundaries of these areas will vary depending on the knowledge and experience of the designer, as well as the specific matrix produced.
3. Method for building the product architecture strategies and effects database
For a meaningful PASE matrix to be efficiently generated from insights in the literature, we built the PASE Database that captures published findings on the effects of product architecture decisions. This section describes how that database was constructed.
3.1. Gathering and categorizing the data
The PASE Database was built to aggregate knowledge observed from the literature about the downstream effects of product architecture on the development process. A systematic literature review was conducted by the lead author in order to find an initial selection of the literature for a large variety of architecture effects that could be processed by the research team. The papers selected were not intended to be comprehensive, but to cover a range of product architecture topics with substantial detail.
3.1.1. Initial literature review and steps for processing sources
In the first step of the literature review, the influential articles The Role of Product Architecture in the Manufacturing Firm by Ulrich (Reference Ulrich1995) and Impact of Modularity Decisions on a Firm’s Economic Objectives by Hackl et al. (Reference Hackl, Krause, Otto, Windheim, Moon, Bursac and Lachmayer2020) were selected. Ulrich (Reference Ulrich1995) was selected as his paper is recognized as a seminal work, having over 4000 citations. In order to include more recent efforts, Hackl et al. (Reference Hackl, Krause, Otto, Windheim, Moon, Bursac and Lachmayer2020) were selected as their research identified many effects of product architecture, was only 2 years old at the time of the literature review and had already been cited over 20 times. Additional papers were then reviewed that were either referenced by these two foundational papers or cited. An initial selection was made of those papers based on keywords pertaining to product architecture in the titles (i.e., product architecture, components, standardization, modularity, interfaces, design and development), resulting in a set of 199 papers. Next, the abstracts of all 199 papers were carefully reviewed, reducing the set to 45 papers the researchers believed had the greatest potential relevance. Finally, the bodies of the remaining articles were read and categorized by which ones best explored key and varied architecture decisions, and their effects on downstream product development activities. As this was not intended to create a final, definitive or comprehensive database, some subjectivity was tolerated to create this initial selection to then be processed.
After reading the 45 papers, nine were identified as being highly likely to reveal the effects of product architecture strategies. These nine papers together with the two papers first referenced are the 11 papers from which the current PASE Database was constructed. All 11 papers (Ulrich, Reference Ulrich1995; Hackl et al., Reference Hackl, Krause, Otto, Windheim, Moon, Bursac and Lachmayer2020; Brusoni et al., Reference Brusoni, Marengo, Prencipe and Valente2007; Clark, Reference Clark1989; Danese and Filippini, Reference Danese and Filippini2010; Eppner et al., Reference Eppner, Höfer, Jonschkowski, Martín-Martín, Sieverling, Wall and Brock2018; Stone and Wood, Reference Stone and Wood2000; Ulrich and Seering, Reference Ulrich and Seering1990; Ulrich and Ellison, Reference Ulrich and Ellison1999, Reference Ulrich and Ellison2005; Wyatt et al., Reference Wyatt, Wynn, Jarrett and Clarkson2012) were read thoroughly and had data extracted and organized into a database, becoming sources. This reduction in the number of papers to be processed was done mainly to maximize the likelihood that time spent extracting data would result in pertinent strategies and effects. Any of the papers identified at the beginning could have been processed, though may not have contained as many relevant statements on product architecture and its effects.
The statements were printed onto 374 cards and using the KJ method (Scupin, Reference Scupin1997) were grouped into categories, first by strategy, and then the strategies themselves were grouped. This was done by three researchers, all with backgrounds in mechanical engineering. These categorized observations were then broken down into their components that would make up the six rational tables of the database: Sources, Statements, Insights, Strategies, Effects, and Relationships, with each entry having its own unique identifier or identifier code. The research team decomposed the statements into their database components using the following steps (Figure 2):
-
1. Read and identify potential statements: A statement is any quotation from a source in which at least one specific decision regarding product architecture led to, or was said to lead to, one or more effects.
Example statement.
ST-001: “Although consumption and wear is frequently accommodated through a modular design with replaceable parts another popular strategy is to dramatically lower the cost of the entire product, often through an integral architecture, such that the entire product can be discarded or recycled.” (Ulrich, Reference Ulrich1995)
-
2. Decompose statements into insights: An insight is a one-to-one pairing of an architectural strategy and one of its effects found within a statement. Wording was kept as close to the original statement as possible, while reorganizing it into a cause-and-effect sentence.
Example insights (from statement ST-001).
I-001: Modular architecture can circumvent wear.
I-002: Integral architecture can circumvent wear.
I-003: Integral architecture can lower the cost of the entire product.
I-004: Integral architecture can facilitate disposable design.
-
3. Group insights and consolidate: Insights were grouped by their causes and had their effects compared. Each insight was constrained to be unique and duplicates within a single source were ignored, as each source must be limited to affirming any specific insight only once. If several statements gave the same insights, then the statements were consolidated, leaving a single statement pointing to a unique insight within each source.
Example consolidation (I-005 is from another statement).
I-003: Integral architecture can lower the cost of the entire product.
I-005: Integral architectures can allow for a lower-cost product.
Note: Similar or identical insights from different sources are not removed as they are seen as multiple sources affirming the same idea.
-
4. Identify standard strategies, effects and relationships: From the groupings of insights, the causes and effects were refined and their language standardized before these parts were placed in the database as architecture strategies and their effects. This helped reduce redundancy within the database, as similar ideas from different sources were recognized despite variation in the wording and terminology used by the various authors.
Next, the strategy and effect pair identified from the insight was recorded as a relationship. If in the database there was no existing strategy or effect that adequately fit the cause and/or effect, a new one was added to the corresponding table in the database. If there were identical relationships, that is, two insights from the same source communicated the same idea, one was removed as in step 3. If there was no existing relationship for the insight (such as when a new strategy or effect was described), then a new relationship was created. Relationships consist of simply their own identifier code, and the identifier codes for a strategy and an effect. Every insight was linked to a relationship’s identifier code.
Example strategy, effect and relationship identification.
Strategies.
ST-001 Use modular architecture.
ST-002 Use integral architecture.
Effects.
E-001 Decreases wear concerns.
E-002 Decreases cost per unit.
E-003 Increases disposability.
Relationships.
R-001: (ST-001 + E-001).
R-002: (ST-002 + E-001).
R-003: (ST-002 + E-002).
R-004: (ST-001 + E-003).
Note: Insights are the key element in the database pointing either forward to a relationship or back toward the statements and sources from which they originated.
-
5. Verify and record all identified components: All new strategies, effects and relationships were compared with any previously recorded in the database to again verify no duplicates had been included. All insights were ensured they linked to an identified relationship and that relationships contained both a strategy and effect. All strategies, effects, insights, relationships, statements and the source were verified having been recorded in their own corresponding table with their own unique identifier code.
Example verification.
R-002:(ST-002 + E-001).
R-005:(ST-002 + E-001).
Special Note: All of the examples in the above steps are taken from Ulrich Reference Ulrich1995. The identifiers follow the format used in the PASE Database and have been reassigned values that correspond to the scope of this example.
Database components.
This database can be expanded upon over time using the same process above for adding sources and their subsequent information to the database. After the initial development, five more sources (Bonvoisin et al., Reference Bonvoisin, Halstenberg, Buchert and Stark2016; Jiao et al., Reference Jiao, Simpson and Siddique2007; Farrell and Simpson, Reference Farrell and Simpson2003; Sosa et al., Reference Sosa, Eppinger and Rowles2000; Kuo et al., Reference Kuo, Huang and Zhang2001) were processed and incorporated into the database, giving additional insights beyond those collected in the initial data. While 16 sources are a relatively small selection, over 450 unique relationships were identified as reported in Section 3.2, providing a significant amount of useful information.
3.1.2. Estimated hours of effort for adding a source
The five new sources were processed individually allowing for time to be tracked for a researcher per source; using the steps listed earlier in this section. It was observed that across three different individuals, it took an average five hours per source. It should be noted that this time varies widely depending on the length of the article and a researcher’s experience with the method. Some researchers were able to complete shorter papers in just over three hours, while longer papers took closer to seven.
3.1.3. Researcher reliability
The experience and number of people used to identify statements from each paper is another factor that may introduce variation in which statements are recorded. In order to better understand the implications of this variation, the paper by Jiao et al. (Reference Jiao, Simpson and Siddique2007) was independently processed as a source by two researchers according to the steps described. Both Researcher 1 and Researcher 2 had technical backgrounds in engineering. Though both had previously coded sources into the PASE Database, Researcher 2 had about 40 man-hours more than Researcher 1. The information added was then reviewed and compared, and key differences are noted in Table 1.
Researcher variance in statements and insights identified
In total, the researchers recorded 33 distinct excerpts from Jiao et al. (Reference Jiao, Simpson and Siddique2007). These excerpts were evaluated to see if they met the definition of a statement, that is, they included at least one specific decision regarding product architecture that led to, or was said to lead to, one or more effects. This evaluation was completed by Researcher 2, with oversight and guidance from the primary author. Debate was an important tool in separating excerpts related to business or design strategies and effects from product architecture strategies and effects.
Of the 33 excerpts recorded, 19 were found to meet the definition of a Statement. Only seven of these 19 statements were noted by both researchers. Five of the statements were only found by Researcher 1, and another seven were unique to Researcher 2. Statements however, do not correlate one to one with insights. The 19 statements contained 44 insights, of which 23% were unique to Researcher 1, 36% to Researcher 2 and 41% were from the statements found by both. This indicates that anywhere from a quarter to one-third of the data could have been lost (or not collected) had only one researcher been used on this source. Regarding the excerpts that were rejected, six were unique to Researcher 1, two were unique to Researcher 2 and six were annotated by both. Thus the ratio of statements to total excerpts recorded was 50% and 64% for Researchers 1 and 2.
Due to the small dataset, no pattern was discernible that might explain the variation between researchers. That said, this exercise demonstrates the benefit of redundant researchers in maximizing the amount of data extracted from a source. This benefit does not extend to the quality of statements recorded. Regardless of the number of individuals used, the steps for processing data sources must be followed and debated to maintain the quality of relationships in the database.
3.2. Database metrics
The PASE Database is the source of information that forms a PASE matrix. At present, it does not contain information about the relative quality of the numerous statements contained therein (statements extracted directly from the literature). While such qualitative information could enhance the PASE Database, we could not confidently extract that information from the literature during this study. However, the quality of the database itself (its construction, the amount of information within, etc.) could be confidently assessed in real time using database metrics. These metrics for the database give insights into its health and quality and are necessary for informed decision-making. These indicators for the consistency and credibility of the database require current, up-to-date metrics to be retrievable from the database in real time. This transparency is critical for user confidence.
Metrics assist in the evaluation of the PASE Database by identifying gaps or limitations in the current database content. This allows the acquisition of additional relevant sources and statements to be prioritized, enhancing the scope and accuracy. Maintaining this iterative process is key for ensuring the database can evolve with the ever-changing knowledge landscape and more effectively produce meaningful PASE matrices.
3.2.1. General database metrics
Listed below are the metrics based on simple counts of the basic elements that make up the PASE Database:
-
• Number of sources
$ \left({N}_s\right) $
: A count of all the archival papers from which came the strategies, effects and relationships in the database. Its current value is
$ {N}_s=16 $
-
• Number of statements
$ \left({N}_m\right) $
: A count of the statements from the source papers that discuss relationships between an architectural strategy and effect. Its current value is
$ {N}_m=438 $
-
• Number of insights
$ \left({N}_i\right) $
: A count of how many separate insights were gleaned from the above statements where a specific relationship between an architectural strategy and an effect was identified. Many of the statements contain multiple insights, and there are multiple insights from different papers that identify the same relationships. However, all duplicate insights from the same paper were removed in constructing the database, even when a paper contained multiple statements with the same insights, as it did not offer another source for supporting the insight. Its current value is
$ {N}_i=641 $
-
• Number of strategies
$ \left({N}_t\right) $
: A count of all the unique strategies that have been identified from the insights. Its current value is
$ {N}_t=38 $
-
• Number of effects
$ \left({N}_e\right) $
: A count of all the unique effects identified from the insights. Its current value is
$ {N}_e=271 $
-
• Number of relationships
$ \left({N}_r\right) $
: A count of the unique relationships linking an architectural strategy to an effect that are recorded in the database. This differs from the insights as each one is unique, while similar or identical insights may be found from multiple sources that all point to the same relationship. This allows for a relationship to connect back to multiple sources (potentially increasing the confidence in that relationship) without duplicating it in the database. Its current value is
$ {N}_r=451 $
3.2.2. Specific database metrics and equations
The metrics listed below are relationships of interest that are computed using the general metrics above:
-
• Ubiquity ratio: The number of sources that reference a given strategy (STR), effect (EFF) or relationship (REL), over the total number of sources in the database. This ratio can serve as a valuable tool in demonstrating the consistency of particular strategies, effects or relationships found in the sources used in the database. Mathematically, this is expressed thus:
$$ {U}_j=\frac{N_j}{N_s}\hskip1em \mathrm{where}\hskip1em j\in \left\{\mathrm{STR},\mathrm{EFF},\mathrm{REL}\right\} $$
with
$ {N}_s $
as the total number of sources in the database. Below are examples of using Equation 1 to compute the current Ubiquity ratios of the strategy Use modular architecture, the effect Decreases product innovation and the relationship between them.
$$ {U}_{STR}=\frac{N_{STR}}{N_s}=15/16 $$
Equation 2 shows that
$ 15/16 $
sources mention the use of modular architecture.
$$ {U}_{EFF}=\frac{N_{EFF}}{N_s}=3/16 $$
Equation 3 indicates that three sources mention decreasing product innovation.
$$ {U}_{REL}=\frac{N_{REL}}{N_s}=2/16 $$
Equation 4 shows that two sources mention the specific relationship where the use of modular architecture can decrease product innovation.
-
• Rare relationship ratio (
$ {R}_c $
): The number of relationships indicated by less than a chosen critical percentage (c) of the sources in the database, over the total number of relationships within the database. For illustration purposes in this paper, 10% was selected for
$ c $
as it indicates a single source in the current PASE Database with 16 sources. This is expressed by Equation 5:
$$ {R}_c=\frac{N_c}{N_s}\hskip1em \mathrm{where}\hskip1em c=10\% $$
The
$ {R}_c $
for the entire database is shown in equation (6), indicating the number of relationships only mentioned by a single source over all relationships in the database:
$$ {R}_c=\frac{249}{451} $$
-
• Source contribution ratio: The number of rare relationships (from Equation 5) that can be identified from any given source, over the total number of relationships identified from that same source. This is expressed with
$ {R}_c $
as the number of rare relationships and
$ {R}_s $
is the total number of relationships from the source, as shown below:
$$ SCR=\frac{R_c}{R_s} $$
Examples of the
$ SCR $
for the first, fourth and sixth sources added to the database are as follows:
$$ {SCR}_1=\frac{68}{83} $$
Equation 8 shows that 68 of the 83 relationships found in the first source (Ulrich, Reference Ulrich1995) are unique to it.
$$ {SCR}_4=\frac{13}{17} $$
Equation 9 shows that in the fourth source (Ulrich and Seering, Reference Ulrich and Seering1990), 13 of its 17 relationships are only found there.
$$ {SCR}_6=\frac{36}{36} $$
Equation 10 reveals all 36 relationships found in the sixth source (Eppner et al., Reference Eppner, Höfer, Jonschkowski, Martín-Martín, Sieverling, Wall and Brock2018) are unique to this paper. This would be an indication to search for more papers to affirm the claims of Eppner et al. (Reference Eppner, Höfer, Jonschkowski, Martín-Martín, Sieverling, Wall and Brock2018) and possibly as an indicator of areas where more research could be done if no other papers on the topic are found.
-
• Saturation plots: These plots indicate how the database changes with the addition of more information. The first type shown in Figure 3 compares the number of relationships (unique within the database) with the number of insights (each unique within a source), with the insights kept in chronological order. The slope of this graph is the rate new relationships are gained from the addition of insights. The maximum slope possible is one-to-one or
$ m=1 $
. The actual slope is useful in showing whether the database is becoming “saturated” where finding insights from sources no longer gives new relationships. Currently the slope is relatively consistent and linear at approximately
$ m\approx 3/4 $
, showing that three relationships are added for about every four insights found in a new source. This indicates that currently adding more sources should continue to consistently add more relationships to the database.In contrast, Figure 4 depicts the number of relationships over the sources, which are also in chronological order. Its slope is useful for planning purposes as one can estimate how many sources (and by extension the time) are required to add any additional number of relationships. Currently this plot shows that the first two sources added (Ulrich, Reference Ulrich1995; Hackl et al., Reference Hackl, Krause, Otto, Windheim, Moon, Bursac and Lachmayer2020) gave many new relationships, and the slope can be approximated for the remaining sources as
$ m\approx 31 $
, or for every new source 31 relationships are found (source 9 was an exception as it gave no new relationships, showing as a flat point on the graph).Full saturation of the database is best indicated when both Figures 3 and 4 approach a horizontal slope
$ \left(m\approx 0\right) $
.
Saturation plot: insights vs. unique relationships.
Saturation plot: sources vs. unique relationships.
4. PASE matrix demonstration
In this section, we discuss the two approaches for creating PASE matrices and demonstrate how a design team could use them to aid in finding and evaluating architecture strategies. Importantly, we show how the matrix can be used to mitigate undesirable effects.
4.1. Effects-driven approach
One approach to create a PASE matrix begins with determining an effect or a set of effects that are of interest. Interest could be due to them being either desirable or undesirable to a particular design project. This selection results in a PASE matrix with a list of strategies of interest derived from the effects of interest. All other effects related to these strategies, and not part of the initial selection of effects of interest, are also added to the matrix as related effects. Some or all of these related effects may be unanticipated by the design team. A generic example is shown in Figure 1.
4.1.1. Using the effects-driven approach with the PASE matrix generator
This approach for constructing the PASE matrix points the designer to strategies to achieve the selected effects of interest and discovers the related effects that also accompany those strategies. The steps for this approach are as follows:
-
1. Select effects of interest (user action)
Select effects from the available list that are anticipated to be needed, probable to occur, or of possible concern for the project.
TIP: Selecting too many effects may cause the matrix to grow too large to display in a concise format.
-
2. Generate and return PASE matrix (PASE matrix generator – automated)
The PASE matrix generator will use the effects of interest selected in step 1 above to identify all strategies of interest linked to these effects in the database. It will then identify the related effects for those strategies in addition to the original effects of interest.
The generator will next form and return to the user a visual readout in the form of a PASE matrix with the identified strategies forming the rows. Columns will be made by listing first the effects of interest, followed by a double line. The remaining related effects are then listed in columns to the right of the double line. A header for both “Effects of Interest” and the “Related Effects” is placed over each group to allow for easy distinction. Relationships between the various strategies and effects are indicated with an “X” at the appropriate intersections of rows and columns (see Figure 1) in accordance with the database.
-
3. Evaluate and select resulting strategies (user action)
Consider each resulting strategy and its set of effects, identifying the significant implications both positive and negative to the design effort. Compare the strategies and their implications, selecting those that best achieve desired effects with the lowest cost in negative effects.
TIP: Implications can be formed using the indicated relationships of the PASE matrix, logical intuition or designer experience.
4.2. Strategy-driven approach
A different approach for creating and using a PASE matrix for any design effort begins with selecting a strategy or strategies of interest. This will result in a PASE matrix with only a set of related effects, some of which may be unanticipated by the design team. Figure 5 shows an example of this approach. The only difference between this approach and the effects-driven approach is the starting point, with strategies selected first and the generator then used to derive effects.
Strategy-driven PASE matrix.
A strategy-driven approach may be desirable when an architecture strategy has been decided upon, or is already in place, and the design team wants to verify that the strategy’s downstream effects are compatible with the system, design or requirements.
4.3. Design scenario
A design team is interested in creating a new product used in industrial agriculture. There are two major concerns for this project, the first being product reliability in a dusty environment with heavy vibrations from moving over rough terrain. The second concern is the ability to maintain the machine to reduce downtime during harvests as the crop can spoil if not harvested within a limited time frame. In this scenario, we recommend beginning with an effects-driven approach and completing the following steps:
4.3.1. Part A: effects-driven approach
-
1. Select effects of interest (design team action)
The team should select the effects of interest such as Increases robustness of design in harsh/unpredictable environments, Increases component Reliability and Maturity and Increases ease of service and maintenance, as effects of interest from the PASE matrix generator’s list as they relate to the specific areas of concern for this project.
-
2. Generate and return PASE matrix (PASE matrix generator – automated)
The generator will list all of the architectural strategies that can lead to the selected effects as recorded in the PASE Database. From this, a PASE matrix is created as shown in Figure 6 (this matrix is truncated from 177 to only 25 related effects for this demonstration).
-
3. Evaluate and select resulting strategies (design team action)
The generator returns a number of strategies in the PASE matrix as shown in Figure 6. Upon inspection, this PASE matrix shows that all three of the desired effects of interest can be achieved by using a combination of two of the strategies: Use modular architecture (which achieves two of the effects) and Use hardware to control product functions (the only strategy for increasing robustness of design in harsh/unpredictable environments). While differing combinations of the other strategies could be used, we chose these two for this demonstration. The team could continue to evaluate the two strategies from this matrix, but to increase clarity for the two strategies identified, we recommend a more focused version of the matrix be created through a strategy-driven approach as shown in Part B.
Part A – Step 2: effects-driven approach.
4.3.2. Part B: strategy-driven approach
Step 1. Select strategy of interest (design team action)
Using the two strategies of interest identified in Part A, the team would select Use modular architecture and Use hardware to control product functions from the PASE matrix generator list.
Step 2. Generate and return PASE matrix (PASE matrix generator – automated).
The generator will list all of the possible downstream or related effects from using the two selected strategies and create a new PASE matrix as shown in Figure 7.
Part B – Step 2: strategy-driven approach.
Step 3. Evaluate effects on strategy selection (design team action)
Examining the focused matrix can lead the team to specific insights such as the following:
-
• Modular architecture can decrease the global (system) performance, which includes things like fuel efficiency. The team will need to decide if the benefits from increasing component reliability, serviceability and maintainability supersede this effect.
-
• Use of hardware to increase stable or gentle interactions may be of great benefit for the type of crop being harvested as it should aid in reducing damage during the harvesting process.
-
• Decreased feasibility for edge-cases may not be a great detriment as this is a machine intended for a specific purpose, and so its value is based less on its flexibility in this scenario.
-
• Both strategies can increase local performance (the performance of specific components) that may be of greater benefit than the loss of global performance they may experience. The importance of the harvesting mechanism’s performance may outweigh any global performance concerns such as fuel efficiency, speed and so forth as the inability to optimize these parameters does not necessarily mean they will be too low for effective function.
4.4. Design scenario insights
The degree to which the strategies selected cause the effects listed in the matrix will depend specifically on how they are implemented. Few of the effects and strategies are of a binary nature, whereas most are on a scale that shifts depending on the specific implementation of a strategy. Using hardware to control functions (e.g., cam-followers) does not mean that no computer controls can be used, but rather the designer intends to rely more on hardware control for a certain function(s). PASE matrices do not design the product but instead give designers information to consider, enabling better decisions.
As a visual summary of relationships, the PASE matrix is necessarily terse and lacks details on how, when and why a strategy causes a certain effect. Two effects may appear contradictory coming from the same strategy, but generally this is due to how the strategy was implemented. While the relationships between strategy and effect are found in the PASE Database’s sources, they do not always offer more detailed explanations. A designer alerted to an unfamiliar relationship by a PASE matrix may have to research it on their own.
Evaluation of strategies and effects does require some understanding and knowledge as to why and when the relationships shown by the PASE matrix are activated or are more likely. This is why the PASE matrix generator also displays the statements from the literature for each relationship, as some help explain the relationship’s conditions.
The interactive nature of a PASE matrix makes it a highly flexible tool for visualizing the content of archival literature in a wide variety of applications. The actual design insights gleaned by a design team from a particular PASE matrix will vary depending on their needs and wants, as well as other situational factors. Some of the relationships and their effects may be deemed trivial to one project, but critical in another. The matrix does not regulate how relationships are considered, but it does create a greater uniformity in what relationships are considered.
5. Concluding remarks
PASE matrices and the PASE Database have been presented as new tools to present findings from archival literature on product architecture to design teams and firms. Making these findings from product architecture research more accessible can elucidate the effects product architecture has on downstream processes, giving firms and teams more information to take advantage of when making design decisions.
Design decisions are the critical aspects of the design process. Displaying architecture strategies with their potential effects in a PASE matrix can enable decisions to be made with greater confidence knowing that what is displayed is from the archival literature. If there are potentially negative effects shown, mitigation can be considered as well.
The architecture strategies and their related effects used to create the PASE matrices were discovered within the sampled literature. From this, it is reasonable to assume that many more exist that can be added to this database further increasing its utility. It must be acknowledged that no database will ever contain all possible sources on the topic of product architecture. However, even this current form of the PASE Database containing only 16 sources can be used to generate PASE matrices with useful content. Adding more sources and their insights to the database will increase its overall utility.
While various AI tools, such as ChatGPT (Kasneci et al., Reference Kasneci, Seßler, Küchemann, Bannert, Dementieva, Fischer, Gasser, Groh, Günnemann and Hüllermeier2023), could also be used to identify some of these relationships, they lack the structured database that links the insights to specific sources and locations within those sources, thus losing traceability. However, AI-based data mining of full paper texts may be a powerful avenue to rapidly grow the PASE Database established in this paper, where the data in this paper will serve as truth data for AI training.
Another outcome of the PASE Database and matrices is that each strategy is only given one row in the PASE matrix. This allows for less popular architecture strategies (those with fewer references in archival literature) to be compared on an equal footing with popular strategies. This removes bias in favoring popular strategies, and when using an effects-driven approach will expose strategies that would not have been considered otherwise. However, there will be more information shown for strategies that have more of their effects documented in the database.
A strategy and effect relationship missing from the database that a designer knows to exist from experience could indicate two possibilities: either a hole in the database, requiring sources on those topics to be added, or more research is needed in that particular area, if a search of the literature also finds a lack of information on it.
While the PASE method provides insights into strategy–effect relationships, it does not yet capture information on the strength of those relationships. This is an area for possible future research.
Databases can be very useful for increasing understanding and accessibility of their material. The cause–effect structure used in the PASE Database could be applied to other areas besides product architecture strategies and effects. Thus similar matrices comparing other factors or decision areas and their effects could be generated to aid in both the design process and more broadly other industry processes. As it stands, the PASE Database and matrices can be valuable tools in understanding the effects of product architecture on the downstream product design and development process, and their usefulness is expected to improve with future additions to the PASE Database.
Acknowledgements
We gratefully acknowledge the United States Air Force Academy for funding this research: Grant number FA7000-21-2-0007.
Open access
