Regular Paper
Characterizing Complex
Product Architectures
David M. Sharman1 and Ali A. Yassine2, *
1
Massachusetts Institute of Technology, Cambridge, MA 02139
2
Department of General Engineering, University of Illinois at Urbana-Champaign, 117 Transportation Building, Urbana,
IL 61801
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
Received 17 April 2003; Accepted 20 August 2003, after one or more revisions
DOI 10.1002/sys.10056
ABSTRACT
Due to the large-scale nature of complex product architectures, it is necessary to develop
some form of abstraction in order to be able to describe and grasp the structure of the product,
facilitating product modularization. In this paper we develop three methods for describing
product architectures: (a) the Dependency Structure Matrix (DSM), (b) Molecular Diagrams
(MD), and (c) Visibility-Dependency (VD) signature diagrams. Each method has its own
language (and abstraction), which can be used to qualitatively or quantitatively characterize
any given architecture spanning the modular-integrated continuum. A consequence of abstraction is the loss of some detail. So, it is important to choose the correct method (and
resolution) to characterize the architecture in order to retain the salient details. The proposed
methods are suited for describing architectures of varying levels of complexity and detail. The
three methods are demonstrated using a sequence of illustrative simple examples and a
case-study analysis of a complex product architecture for an industrial gas turbine. © 2003
Wiley Periodicals, Inc. Syst Eng 7: 35–60, 2004
Key words: dependency structure matrix; design rules; modularity; product architecture;
visibility and dependency; characterization; molecular diagrams; architectural signature
1. INTRODUCTION
upon the ability to describe. However, describing complex product architectures poses essential problems as
they tend to be large scale, heterogeneous, and interdisciplinary.
Because of the large scale of complex architectures,
it is necessary to use some form of abstraction in order
to be able to grasp the structure of the whole. A consequence of abstraction is the loss of detail, and it is
important to choose the correct resolution to view the
The first step in any analysis is description, and later
steps often include elements of comparison, which rely
*Author to whom all correspondence should be addressed (e-mail:
[email protected]).
Systems Engineering, Vol. 7, No. 1, 2004
© 2003 Wiley Periodicals, Inc.
35
36
SHARMAN AND YASSINE
architecture so that salient details are retained. Unfortunately, a characteristic of complex architectures is that
they tend to be heterogeneous—they are not merely
repetitive large-scale structures—and thus the salient
details in one area of the structure may only emerge at
a level of detail that is too great a resolution for another
area. This has led to many different schemes for portraying complex architectures each of which allows
variable levels of resolution, depending on the relative
importance of nuances of the structure (e.g., hierarchy
diagrams, object-oriented descriptions, dependency
structure matrix, cause and effect diagrams, flowcharts,
etc.). While these are helpful, they tend to be specialized
in their use, and it is difficult to use them as a descriptive
technique for interdisciplinary analysis of complex
products, or where individual products integrate multiple disciplines (the typical problems being at the interface of software—hardware or static—process
interface).
This paper proposes and describes three different
ways to represent complex product architectures. Each
seems best suited to a different level of resolution and
each has proven useful in analyzing a particular case of
a complex product. What links them together as descriptive models is their reliance on manipulating the
data encoded in a Dependency Structure Matrix (DSM)
in order to arrive at the desired abstraction. The strength
of these three approaches is that they appear to be
product-type independent and are able to cope with
heterogeneous architectures. To varying extents each is
amenable to use in both a qualitative and quantitative
manner. The three representation methods are:
1. Micro-level DSM cartoons and related language
2. Intermediate level molecular diagrams
3. Macro-level visibility-dependence signature diagrams and related characteristics
The category of manmade products known as complex systems are often decomposed into a number of
simpler sub-systems (i.e., modules) that can be controlled independently, and whose collective individual behaviors yield the performance of the original complex
system. Proper decomposition of design development
into modules is concerned with assigning into the same
module development tasks that are anticipated to require high problem-solving interaction, while assigning
to different modules the tasks that require low problemsolving interaction.
Even though decomposition of the development effort normally reduces the technical complexity of development, it creates a serious managerial challenge
due to the complex web of dependencies and interactions between the modules, which require careful man-
agement. Therefore, analysis of product decompositions provides valuable insights into the structure of the
product and the choice of architecture. Ulrich and Eppinger [2000] define product architecture as the scheme
by which the decomposed elements are arranged in
modules. The less interacting these modules are, the
more modular the product architecture is.
Modularity as a strategy can be employed for different reasons. In the right circumstances it allows increased product or organizational variety [Ulrich and
Eppinger, 2000] increased rates of technological or
social innovation [Baldwin and Clark, 2000]; reduces
costs through reuse; more sharply defines the opportunities for market dominance through interface capture
[Moore, 1999]; and the increased specialization at firm
level may allow more flexible response to environmental change [Sanchez and Mahoney, 1996]. But
modularity has drawbacks. In its extreme form the
intermodule interfaces must allow change to occur
within modules without adversely affecting intermodule working, and this is beneficial only if the choice
of element division into modules is optimal, if all elements are divided into unique modules, and if all intermodule relationships are then completely described in
interface descriptions that also fully describe the emergent system-level characteristics. Such a harmonious
state only occurs when designers well understand the
product so that they are able to describe completely and
clearly optimal interface rules, while premature modularization adversely affects the system-level tradespace.
This paper uses the Dependency Structure Matrix
(DSM) as the underlying model for representing a
product’s architecture. Direct inspection of the DSM
itself is one valid way of interpreting the product’s
architecture. This tends to be of most use when the
product is both of relatively small scale and has internal
relationships of low complexity. However, as we show
in this paper, it does not take much of an increase in
complexity for direct inspection of DSMs to become
unsatisfactory as a way of grasping the overall architecture. Similarly, although not discussed at length, a
growth in the scale of a product to more than a few
hundred elements makes it difficult to read a DSM
directly. Nevertheless, there seems no better disciplineindependent way of understanding the micro architecture of a product than to inspect the DSM.1
As scale and complexity increase, it becomes more
sensible to observe where the levers of control are in the
product’s architecture. This leads us to the twin notions
1
The micro-architecture of a product is the architecture which
one sees at a relatively high level of (i.e., detailed) resolution such as
that used to see down through three or more layers of abstraction (e.g.,
product, subsystems, modules, and then elements/components).
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
of visibility and dependency in an architecture and
consideration of these suggests that all architectures
posses a characteristic visibility-dependency signature.
This appears a useful way of viewing large-scale complex systems at a macroscopic level, and we show how
to display these signatures.
A drawback with visibility-dependency signatures
and DSMs is that they are not always easily appreciated
at first glance by an untrained or nontechnical audience.
For this reason we have developed the intermediate
level representation that we term the molecular diagram. At present this is a very flexible and somewhat
arbitrarily crafted device and as such is necessarily less
mature, but nevertheless initial anecdotal responses
from users has been that it enables them to “get it”
sufficient to be able to contribute meaningfully to high
level discussions and without imposing arbitrary solutions. Each of these three techniques has been deliberately chosen to address the representation problems
posed by complex products. That is, they are capable of
coping with large-scale systems spanning multiple disciplines and possessing areas of differing levels of
complexity.
The rest of the paper proceeds as follows. In the next
section we describe some different pictorial representation systems used in engineering and discuss their
respective limitations. Then we introduce the Dependency Structure Matrix (DSM) method in Section 3.
Following this, Section 4 introduces the fundamental
analysis techniques used in the DSM to characterize a
product’s architecture and identify modular clusters,
and closes by introducing the closely related topic of
molecular diagrams. Section 5 describes visibility and
dependency and how these are affected by whether
architectures are hierarchical or recursive, and binary or
nonbinary; as well as other generic and quantifiable
characteristics of architectural signatures. Section 6
applies this to the case study of a gas turbine generator
set, and Section 7 contains the conclusions and notes
regarding further work.
2. PICTORIAL REPRESENTATION IN
ENGINEERING
The engineering community has a long tradition of
building models to represent various engineering artefacts. These models range from simple 2-dimensional
freehand sketches to complex 3-dimensional CAD
models.2 Moreover, these models range in their level of
abstraction from highly abstract (e.g., mathematical
2
A model is an abstraction of an object (e.g., a designed artifact),
a system (e.g., an automotive transmission), or a process (e.g., the
process of designing a shaft), and is typically constructed for representation and analysis [Kusiak, 1999].
37
models) to the less abstract (e.g., physical prototypes).
However, in this section we will restrict our discussion
to a special type of engineering models: visual (or
pictorial) models. A pictorial model provides sufficient
understanding of the “thing” being modeled and visual
access to the subtle and the complex. The key is to
provide an “honest” portrayal of complexity and not the
complication of the simple [Tufte, 1983].
Table I provides a nonexhaustive list of such visual
models, which are extensively used within the engineering community. Even though these models may serve
different purposes and be employed at different times
within the engineering design process, they all share a
common goal of visually displaying quantitative information, which is otherwise not as easily accessible to
the engineer or analyst.
Investigating existing engineering models, to assess
their utility in describing and analyzing product architectures, we observed that many, such as CAD models
and function diagrams, are specific to either a product
type, or to an engineering discipline, and do not enable
analysis between products or across disciplines. An
example is that a CAD drawing of the mechanical
layout of a PC provides no feel for the importance or
complexity of either the electronic design or the software. Although function drawings can provide crossdiscipline information, they have great difficulty in
conveying nonhierarchical information as we discuss
below.
In engineering design, for example, CAD models of
parts or assemblies are the norm nowadays. However,
these models, even though extremely useful for product
realization, are not as useful for analyzing architectural
properties. A more relevant model is a function diagram
[Otto and Wood, 2001]. The technique starts with creating a function structure for the product under consideration.3 This is followed by clustering or grouping the
subfunctions into modular chunks. The method is useful in developing modular product architectures for new
products rather than analyzing the architecture of existing products. Furthermore, it relies on an undirected
search for modules in the structure.
Other techniques such as Hatley/Pirbhai method
[Zakarian and Rushton, 2001], and interaction graphs
[Kusiak and Huang, 1996] have been also proposed for
the development of modular products. Even though
these methods utilize either a matrix form or a network
representation to carry out the modularity analysis, they
tend to be more helpful for analysis rather than representation in comparison to DSM models. Furthermore,
most of these methods rely on mapping the functional
3
A function structure is an input–output diagram of what a
product does [Otto and Wood, 2001].
38
SHARMAN AND YASSINE
Table I. Visual Models in Engineering
decomposition of the product to the product (physical)
architecture. For example, Pahl and Beitz [1999] directly link the definition of modules to functionality
(i.e., basic, auxiliary, special, and adaptive). A module
in this way is the physical realization of a function, and
the whole interface problem (between physical components) is not addressed. On the other hand, this paper
(i.e., DSM models of representation) does not address
itself to the function/form relationship (i.e., does not
require a functional decomposition as a prerequisite for
modularity analysis) and rely merely on the physical
components composing the product, and the interaction
among them, to describe and characterize product
modularity.
Finally, other existing methods are essentially hierarchical (e.g., IDEF models, functional diagrams, and
hierarchy diagrams), an assumption that can be easily
violated in complex architectures. This is particularly
true of systems with relatively high-energy interactions
[Whitney, 1996], where the performance of the system
as a whole is critically dependent upon interactions
between subsystems. This is most evident in highly
integrated products such as in the automotive and aerospace sector. That a nonhierarchical system exists is
easy to appreciate by attempting to draft a function
diagram for the system—and observing that there are
many possible alternate decompositions into superficially hierarchical structures, each of which loses many
of the essential interactions.
In this paper, we use a matrix representation for the
capture and display of product architecture [Pimmler
and Eppinger, 1994]. The model is called the Dependency Structure matrix (DSM). In a DSM model, the
elements within a system (i.e., components and subsystems) are listed and the relationship among them is
vividly displayed. This matrix representation is compact, easily understood, and it allows us to develop
rigorous search and computation algorithms to find
certain architectural features and optimal module configurations [Browning, 2001, 2002].
3. AN OVERVIEW OF THE DEPENDENCY
STRUCTURE MATRIX (DSM)
The Dependency Structure Matrix (DSM)4 is an information exchange model which allows managers to represent important system (or task) relationships in order
to determine a sensible arrangement (or sequence) for
the system (or project) being modeled. In this section,
we describe the basic DSM method and how it can be
used to model product architectures (or projects), determine the dependency structure between the system
elements (or information flows within a project), and to
more accurately identify a product (or project) architecture.
A DSM is a matrix representation of a directed
graph. The nodes of the graph correspond to the column
and row headings in the matrix and the arrows correspond to the marks inside the matrix.5 For example, if
there is an arrow from node C to node A, then a mark
(such as “X” or “•”) is placed in row A and column C
(see Figs. 1 and 2). Generally diagonal elements have
no significance and are normally blacked-out.
A systematic taxonomy and a quantification scheme
may also assist in the analysis by categorizing types of
interactions among DSM elements and associating an
appropriate weight to each. Tables II and III represent
the classification of interactions and an example of a
quantification scheme proposed by Pimmler and Eppinger [1994] as modified by Sharman [2002].6
There are four different types of DSM models applied to various levels of abstraction [Browning, 2001].
The Task (or process domain) DSM model describes the
4
DSM also stands for Design Structure Matrix—in this paper
the two meanings are synonymous.
5
There are different ways of building a DSM, and two different
sign conventions in use. In this paper we place feed forwards below
the diagonal, i.e., counterclockwise. For a full description on these
issues, refer to the DSM website at http://www.DSMweb.org.
6
The four-point scale shown here was the minimum required
in practice to reliably discern clusters. Finer scales seem likely to be
of little benefit as other factors such as uncertainty in estimating the
true value become dominant.
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
Figure 1. The DSM model.
Figure 2. Clustering example.
Table II. Simple Taxonomy of System Element Interactions
Table III. Four Point Scale to Quantify Relationship Strengths Used in Physical DSM
39
40
SHARMAN AND YASSINE
interactions between design tasks. A variation of this
DSM type is the Parameter DSM, which takes a deeper
look into the tasks by decomposing them further into
design parameters delivered by each task. A parameter
DSM describes how does the parameters influence each
other and in what order they should be determined to
minimize guessing and feedback. Thus, as with task
DSMs, partitioning is the commonly used analysis technique for streamlining the sequence of parameter calculations. The third DSM type is called Team (or
organizational domain) DSM. This DSM model is used
for organizational analysis and team formations based
on the intensity and frequency of information flow
among various organizational entities (i.e., development participants). Finally, the Component (or physical
domain) DSM documents interactions between elements of a complex system architecture. For the latter
two DSM models, clustering is typically used to rearrange the DSM and identify improved team formations
or improved product architecture.
3.1. DSM Analysis Techniques
If the DSM elements represent tasks to be performed,
then inspecting the row and column of a task reveals the
inputs and outputs, respectively, for that task. For example, in Figure 1(a), B feeds C, F, G, J, and K, while
E, F, and L feed D. If there is a time sequence associated
with the position of the elements in the matrix, then all
marks above the diagonal are considered feedback
marks. Feedback marks correspond to required inputs
that are not available at the time of executing a task. In
this case, the execution of the dependent task will be
based on assumptions regarding the status of the input
tasks. As the project unfolds, these assumptions are
revised in light of new information, and the dependent
task is reexecuted if needed (i.e., design iteration).
The matrix can be manipulated in order to eliminate
or reduce the feedback marks. This process is called
partitioning [Steward, 1981]. When this is done, a transparent structure for the project starts to emerge. We can
see which tasks are sequential, which ones can be done
in parallel, and which ones are coupled or iterative [see
Fig. 1(b)]. In partitioning, the main objective is to move
the feedback marks from the above the diagonal to
below the diagonal, given that the DSM elements are
tasks to be executed. However, when the DSM elements
are people in charge of these tasks, system elements, or
components of a larger system, then we have a different
objective for arranging the DSM. The new goal becomes finding subsets of DSM elements (i.e., clusters
or modules—sometimes also termed chunks) that are
mutually exclusive or minimally interacting. This process is referred to as clustering. In other words, clusters
contain most, if not all, of the interactions (i.e., DSM
marks) internally and the interactions or links between
separate clusters is eliminated or minimized [Fernandez, 1998]. In which case, the blocks become analogous
to team formations or independent modules of a system
(i.e., product architecture). Furthermore, in this setting,
marks below the diagonal are synonymous to marks
above the diagonal and they represent interactions between the teams or interfaces between the modules. As
an example, consider the DSM in Figure 2(a). The
entries in the matrix represent the frequency and/or
intensity of communication exchanged between the
different development participants, represented by person A, person B, et al.
As can be seen in Figure 2(b), the original DSM was
rearranged to contain most of the interactions within
two separate blocks: AF and EDBCG. However, three
interactions are still outside any block (i.e., team) and
constitute the points of interaction/collaboration between the two teams. An alterative team arrangement is
suggested in Figure 2(c). This arrangement suggests the
forming of two overlapping teams (i.e., AFE and
EDBCG) where one person (i.e., E) belongs to both
teams and may act as a liaison person.
3.2. Clustering Algorithms
Early clustering algorithms and underlying principles
are described in Alexander [1964]. These algorithms
work in either a top-down or a bottom-up manner, either
by cleaving along the line of least resistance or by
aggregating along the path of greatest return. In either
case, the relevant metric is some function of the number
of linkages that cross a partition boundary. In Alexander’s work, this objective function was implemented
with a simple hill climbing search strategy whereby the
system either was successively partitioned into eversmaller sets or successively aggregated into ever-larger
sets, one element at a time. Further details of clustering
algorithms and a wide range of applications can be
found in Hartigan [1975].
Fernandez [1998] and Thebeau [2001] used a similar
approach to Alexander’s bottom-up aggregation. Each
element is placed in an individual set and bids evaluated
from all the other sets (clusters). If any cluster is able to
make a bid that is better than the current base case, then
the element is moved inside the cluster. The objective
function is therefore a tradeoff between the costs of
being inside a cluster and the overall system benefit.
Existing clustering algorithms [e.g., Fernandez,
1998; Thebeau, 2001] were applied to the generator set
example of Section 6. As a result, we observed that these
algorithms were unable to handle complex integrated
architectures. In investigating the underlying reasons
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
41
Figure 3. Conceptual illustration of the problem of depicting and interpreting complex architectures.
for this difficulty, we developed a language to describe
architectures and then were able to observe and describe
complexity issues such as path dependency, dimensionality, and boundary definition that are of fundamental
importance in handling non-trivial architectures. This
allows us to explain why DSMs in general, and clustering algorithms in particular, experience difficulties in
handling architectures of the nature illustrated in Figure
3, and the caution that must be taken in interpreting
DSMs of such complex architectures.
4. DSM BUILDING BLOCKS;
ARCHITECTURAL/MOLECULAR DIAGRAMS
In this section, we define the basic syntax and semantics
for scrutinizing DSMs in order to characterize the architecture of a complex system. We introduce the notion
of a product being composed of elemental chunks
which can be organized into modules. Chunks can be
attached to each other in different ways, and, when a
chunk becomes the carrier for other chunks, it is termed
a bus. We further explain the concepts of pinning and
holding away that can cause weak buses to become
stranded away from the main bus. We then go on to
discuss issues around the process of arranging product
architectures including the notion of path dependency
in clustering, dimensions, and topology.
The analysis proceeds using simplified (i.e., cartoon) architectures that are described using DSMs,
physical schematics, and basic architectural diagrams
in order to introduce and define the terminology required to develop the underlying constructs with the
minimal amount of complicatedness. These simple constructs will be used later in the paper to analyze more
complex product architectures and are the basis for
developing better automated clustering algorithms [Yu,
Yassine, and Goldberg, 2003].
4.1. Buses, Chunks, and Modules
Figure 4 is a relatively simple example of five related
(i.e., connected) parts. Four parts are connected to a
fifth, and three of these four connections are of equal
strength. This is shown on the left as a physical schematic that can be thought of as representing a flow of
mass, energy, information, or force/geometrical constraint between the parts.
This situation may be visualized as E being some
form of system level integrating component, or bus,
which is connected to parts A, B, C, and D [Fig. 4(a)].
In this instance, the relationships between the parts are
symmetrical; i.e., part A depends on part E in the same
way that part E does on A. To the right of the schematic,
the DSM for this system is drawn [Fig. 4(b)]. A small
“x” represents a weak relationship (i.e., connection or
dependence), and a large “X” represents a strong relationship. To the right of the DSM, a more conceptual
architectural diagram that represents the same situation
is shown [Fig. 4(c)]. This third diagram [Fig. 4(c)] can
be drawn in any orientation as the relationships are
symmetrical; thus at this stage no value should be
assigned to any convention that chooses to draw part E
above rather than below or to the side.
A part is the smallest possible decomposition of
something while a chunk or element could be assem-
42
SHARMAN AND YASSINE
Figure 4. Simple bus, four chunks, no modules.
blies in their own right. For this reason strict terminology should differentiate between primitive elements
(i.e., parts) or higher-level elements (i.e., chunks). We
term a bus as being “simple” when it is a primitive
element.
In Figure 5, we introduce more relationships between parts. In this instance, the pair of parts A and B
is related symmetrically to each other as well as each
possessing an equal relationship with part E. A similar
structure can be seen in the pair of parts C and D. In the
DSM, we define this pairing as being a modular cluster
and denote it by the (two letter) description “Module
SS” and “Module TT.”7
The significance of being a modular cluster is that
all the parts within the module possess the same relationships with each other and with parts outside of the
module—this can be thought of as being the design
rules of the module. In this instance, the modularity is
perfect. In other cases, modules will be similar rather
than identical. In this case, representing them as modules implies either that the module must be overspecified (in order to achieve all the functions) or that the
performance will suffer (where only functionality present in all clusters is included in the standard module
design). We term this imperfect modularization, which
it is a feature of many designs that use modules as
platforms that are then tailored.
The design rules governing modules SS and TT are
different from those governing the bus module. The
value orientation of the conceptual architectural diagram has still not been specified as the DSM denotes
symmetrical relationships between chunks. However,
in the absence of asymmetry the bus would tend to be
more important as its design rules have a greater visibility than those of the modules SS and TT.
4.2. Asymmetry
in Figure 6, where the modular bus VV is more dependent on the modules SS, TT, and UU than the reverse.
Where this is the case, pictorial conventions become
more important in indicating the value gradient, and it
is necessary to explicitly denote the direction of control
to avoid ambiguity.
What do arrows or orientation denote about dependency in Figure 6? The bus module VV is dependent on
all other modules and not the reverse. Therefore, in this
instance, the arrows flow from the power source to the
sink, and the orientation is with the higher value relationships at the bottom and not the top.
4.3. Further Concepts: Pinning and
Holding Away—Imperfection
Many architectures are more complicated than the examples inspected above. Figure 7 shows many possibilities. Either (A, B) and (C, D) can be concatenated
into modules, the sequence A through F be thought of
as one super module, an intermediate module TT be
sandwiched between module SS (comprising A, B) and
module UU (comprising E, F), or simply described as
being comprised of the primitives A through F with the
bus module.
This example also illustrates the notions of “pinning” and “holding away.” Here B is pinned in place
between A and C by its relationship with A and C. This
is a common and easily appreciated situation in much
physical architecture. A less easily appreciated situation
is that of “holding away,” which is seen here in that
element A is held away from element C by element B.
The combination of these two notions assists in describing the drawbacks of various clustering arrangements
and clustering heuristics. Pinning can only occur to
compound elements (modules) that have relationships
with two modules, while any primitive element can be
held away.
There are occasions where asymmetric physical domain relationships occur as illustrated by the example
4.4. Auxiliary, Weak, or Subsidiary Buses
7
Note that buses may also be comprised of multiple primitive
elements, in which case they may be referred to as a “bus module.”
It is possible that elements within a module are pinned
in place in the center of a sequence, or are primitives
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
Figure 5. Simple bus, four chunks, two modules.
Figure 6. Multiple bus; six chunks of three modules.
Figure 7. Imperfection, pinning and holding away.
43
44
SHARMAN AND YASSINE
held away from the main bus by a sequence that is
pinned to the main bus, yet have buslike characteristics.
If this is the case, the clustering algorithm will be forced
to make a choice between disrupting modules adjacent
to the main bus or forgoing the clustering opportunity.
In the latter situation weak buses occur—computer
science literature occasionally refers to the concept of
an auxiliary bus or subsidiary bus, which is why the
alternative descriptions are noted.
This concept is illustrated in Figure 8, where the
primitive element D is pinned firmly in place in the
middle of a sequence yet has weak relationships with
much of the system. In the absence of the strong pins to
the adjacent elements, the weak system-wide relationships would cause it naturally to be incorporated into
the main bus; however, this migration cannot take place,
and so the weak bus remains stranded. In a real world
system this would represent an element whose design
has not only to take into account the upstream and
downstream relationships with C and E, and the bus
UU, but which also has to reach an accommodation
with A, B, and F. Unsurprisingly, any designer or maintainer of such an element will find it difficult to keep
track of and optimize all the possible causes and effects.
This difficulty in visualizing the problem space is evident in the various unsatisfactory conceptual architectural diagrams on the right of Figure 8.
In some respect, auxiliary buses arise because the
“busness” of the element is less strong than either the
modularity of the element (if it is pinned in a module),
or the modularity of the elements that are holding it
away. Thus the notional objective function is being
asked to choose between two undesirable options—disrupt a module or force a bus out into an auxiliary
bus—is guided in its choice by a comparison between
the degree of perfection of the outcome. The choice will
often also be path-dependent, if a nonexhaustive search
is conducted, as the relative goodness of the choices will
be determined by prior choices that have chosen to
emphasize one alternative over another.
4.5. Clustering and Multiple Dimensions
A problem with applying automated clustering algorithms to some complex DSMs is that they find it very
hard to extract the relevant information from the data,
and then to convey it to the user. This is most obvious
in poor handling of pinned modules, buses, and pathdependent situations. We investigate this further in the
rest of this section.
4.5.1. Path Dependency in Clustering
Consider a triangular arrangement of symmetrical relationships that can be loosely clustered into three similar
modules AA, BB, and CC, as shown in Figure 9. The
DSM for this can only ever show one of the real clusters
and must progressively break up the second and third.
The way in which the clustering algorithm operates will
be path-dependent inasmuch as once it has started to
cluster on any nodes it is unlikely to ever reverse out to
a different configuration. This situation may occur because of the way in which raw data is presented to the
clustering algorithm (for example, branch and bound
algorithms that are presented with a partially clustered
starting point may never branch widely enough to
Figure 8. Auxiliary or weak or subsidiary buses.
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
45
Figure 9. Planar triangular clusters.
evaluate alternative solutions) or may arise through
chance if a perfectly random starting point is presented
to an algorithm that makes an initial random guess. In
the example below, cluster CC has been largely broken
up even though it is identical in all respects to the other
two clusters.
This path dependency situation arises because of a
scarcity of dimensions. It is simply difficult to represent
the two dimensional triangle in the one-dimensional
space of a DSM.8 Theoretically, one could cluster in
multiple dimensions (while still remaining within the
physical domain), and there may be merit in examining
the possibilities this offers. A more important practical
point in the short term is to test algorithms for overstability as one would prefer algorithms that search widely
for optimal clustering solutions yet are robust.
4.5.2. Dimensions and Topology
In the planar triangular cluster AA, BB, CC that we saw
above there is a simple and clear structure. The equivalent DSM is able to map the AA-BB clusters in a way
that is easily interpretable. As previously mentioned,
the manner in which this is clustered (interpreted) in a
DSM will depend on the extent to which the clustering
algorithm is path dependent. It could as easily have been
AA or BB clusters that were broken up by being positioned where CC is.
This is relevant because normally the DSM is what
is used to interpret the underlying structure. The correct
question to ask is: “If one is only aware of the information within the DSM, can one see what the real
structure of the thing is?” as, otherwise, one may make
erroneous simplifications or introduce false complex8
In order to best illustrate this point, the extreme form of
clustering with exclusive assignment of elements to sets (modular
clusters) has been used. The point remains valid, albeit to a lesser
extent if nonexclusive assignment is employed and it then becomes
dependent on the notional costs and benefits associated with boundaries as well as random issues associated with path dependency.
ity. So, in this example the real structure might falsely
be interpreted as being two heavy modules and a light
module, and it could simply be chance that determines
which is perceived as being the lightweight module. In
planar rings it seems reasonable that the clear simple
structure could be seen by inspection, so let us turn to
more interesting examples.
The simplest three-dimensional structure is a tetrahedron or 3-dimensional pyramid, depicted in Figure
10 showing four equal clusters, each with dense internal
relationships and weaker (or sparser) external relationships.
As before, if all the clusters are perfectly equal, it is
purely a matter of chance how any clustering algorithm
would present an answer. In the example shown below,
cluster DD is the one that is visually disrupted most by
being presented last in the sequence. This has the effect
of spreading its intercluster relationships over a wider
spatial area, which is depicted in the macro-scale DSM
as being lower density blocks of grey. To an untrained
observer this might be thought to be a bus structure
where cluster DD is the unique possessor of system
wide integrating functions and some semirandom
crosslinking occurs in the zone AA-CC.
Indeed, it is only with knowledge of exactly what the
roles of the elements are in each cluster that a human
would have been able to intuit that DD should be the
bus as opposed to any other cluster. Often this intuition
will have been right, but if there is any dynamicism in
the architecture, one can easily see how historical value
judgments as to what is more or less important can be
prone to rapid disruption as a new entrant (with a new
perspective) realizes the dislocating impact of any
creeping changes in underlying structure. In these situations, the value judgments inherent in assigning a
particular grouping to the “bus” become a historical
liability.
Given the importance of reducing complexity and
minimizing artificial boundaries in an architecture (ir-
46
SHARMAN AND YASSINE
Figure 10. Tetrahedron of clusters.
respective of domain), it is somewhat surprising that so
few architectural diagrams (e.g., hierarchical product
decompositions or organization diagrams) use anything
other than planar representations. This tetrahedron is a
perfectly simple elegant little structure when perceived
in three dimensions, yet is terribly complicated when
seen in only two.
4.6. Molecular Diagrams
The detailed interpretation of the DSM itself and the
drawing of cartoon hierarchies are adequate for microlevel description; however, large DSMs representing
nonplanar architectures can be difficult to intuit. An
alternative is something we term a 3-dimensional molecular diagram.
A molecular diagram is akin to the cartoon hierarchies inasmuch as it is a pictorial network. However,
cartoon hierarchies become swamped in large-scale
networks, and so we choose to condense multiple
highly related elements together. The size of the resultant molecule is then representative of the size of the
component elements. The intermolecular arcs represent
visibility in such a network. If computation allows, it is
possible for the density of the molecules to represent
the interelement visibility within the molecule.
How one selects which elements to condense into
which molecules is up to the user. For our purposes we
have typically used clustering algorithms and/or manual clustering guided by our micro-level understanding
of problems with clustering. However, other users may
have other needs. In the molecular diagram, elements
and arcs that fall beneath threshold criteria may be
omitted for clarity.
Such molecular diagrams are a natural outgrowth of
cartoon hierarchical drawings. They provide an intermediate level of abstraction between cartoon hierarchies and visibility-dependency plots (which will be
discussed next), which we have found useful in visualizing the structure of large-scale complex architectures.
Ideally a molecular diagram should have clear definitions for the meaning of the size of the various pictorial
elements (e.g., molecule size; molecule color and density; arc weight and arrow head conventions), but until
now we have found it adequate to use our judgment.9
Some examples of very simple molecular diagrams
were introduced from Figure 9 onwards in the description of path dependency issues. These were used to
illustrate points regarding hypothetical architectures
without needing to include irrelevant and potentially
misleading detail. In Section 6, the molecular diagram
9
This is an area where further research is likely to be fruitful;
especially, in order to automate the generation of molecular diagrams
for large and complex systems. One such tool that allows the generation of 3D UML diagrams is WilmaScope software, which can be
downloaded for free from http://www.wilmascope.org/.
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
47
Figure 11. Three-level design hierarchy [adapted from Baldwin and Clark, 2000].
of a typical real complex product is developed illustrating the typical level of detail that a molecular diagram
might show.
We wish to emphasize that molecular diagrams are
not yet as highly developed as either DSMs or visibility-dependency plots. There are many variables that
control their presentation, and, as yet, no agreement on
which variables are most important and what should be
the typical settings. As such, molecular diagrams are a
very immature area that we are introducing for the first
time.10
5. DESIGN HIERARCHIES; VISIBILITY
AND DEPENDENCY
Baldwin and Clark [2000] take the stance that for
modularization to work in practice, architects must
partition design parameters into two categories: visible
information and hidden information. Only visible information may interact outside a module, and so a good
modular design will contain interface specifications
that serve to decouple hidden information from visible
information to allow designers the maximum flexibility.
The relationship between hidden and visible information can be represented in a design hierarchy [Baldwin and Clark, 2000]. The left side of Figure 11
represents an example of a design hierarchy, and the
right side depicts the equivalent DSM representation.
In this example, there are three levels of visibility:
global design rules (at the top); locally visible intermediate level design rules (interface rules in this example);
and intramodule design rules (at the bottom of the
hierarchy).
10
There is evidence to suggest that 3-dimensional representations of connected graphs have advantages in conveying software products architecture to users over 2-dimensional graph
representations [Dwyer, 2001].
With a three-level hierarchy, a design rule may be
directly visible to a module below it (i.e., a line links
the two boxes) or indirectly visible via an intermediate
level rule. In this example, the global rules are visible
to all of the system, each set of interface rules is visible
to 3/7 of the system, and each set of module rules is
visible to 1/7 of the system. This approach to visibility
is, of course, only valid while the system is a nested
hierarchy where information (or design rules) only
flows downwards. In order for this to be achievable the
system level design rules must be—for all practical
purposes—scale-independent. If such a nested hierarchy exists, only one element may be at the apex.
5.1. Visibility Calculation
In this section we describe what visibility is and how to
calculate it by introducing simple binary hierarchical
systems first. Then, we consider nonbinary and nonhierarchical systems, refining the calculation process
and creating more precise definitions of visibility and
dependency as necessary.11
To calculate visibility for any element in a system,
we need to ask, “What other elements would need to be
redesigned if this element changed?” So in the system
of Figure 12, a change in element A will directly have
consequences for elements B and D, and indirectly have
consequences for elements C and E. However, a change
in element B only has consequences for element C and
not for A, D, or E. If we make the assumption that B is
100% dependent on A for its design parameters (and
likewise all other links are set as 100%—an assumption
we will later vary), then by inspection we can say that
A is visible to 100% of the system.
11
It is worth noting that our calculation of visibility is different
than those introduced by Baldwin and Clark [2000] despite the fact
we use the same notion. While their calculations allow for only
hierarchical structures, ours include both hierarchical and nonhierarchical.
48
SHARMAN AND YASSINE
Figure 12. Binary hierarchical system.
When discussing “visibility to the system,” there
are two different definitions of “the system”: the system
exclusive of the element in question; or the system
inclusive of the element in question. So, by inspection,
B is visible to 40% of the system including itself (i.e.,
is visible to 2 of 5 elements), or to 25% of the system
exclusive of itself (i.e., is visible to 1 of 4 elements).12
In practice, it normally does not greatly matter which is
used for characterization purposes provided that the
system is sufficiently large.
If the strength of the link is taken to denote the
probability of a redesign of the dependent element
being necessary given that a change has occurred in the
feeding element, then it is possible to analyze more
complex architectures. The system of Figure 12 can be
represented by the leftmost DSM of Figure 13.13 Then
the reachability matrix [Warfield, 1973] gives us the
numbers of steps that any one element can be reached
from another in a network. In its simplest form, it is the
initial DSM raised to successively higher powers as
shown in the central DSMs of Figure 13 for the same
system.
For example, in this figure the circled cell in the
square of the initial DSM shows us that element E can
be reached from element A in two steps and that the
pathway taken has a 100% total probability of causing
redesign. Note that the cube of the initial DSM is not
populated, indicating there are a maximum of two steps
possible in this system. Lastly, by summing across the
arrays we populate a summation DSM at the right of
Figure 13 in which each cell represents the probability
of an element affecting another element by all the
possible routes. The sum of the columns then reveals
the impact of each element on the total system. Since
the initial DSM does not include any element’s influence on itself the column sums are the exclusive visi12
Throughout this paper we make the simplifying assumption
that all elements are of equal size when calculating the size of the
system, and therefore visibility within the system.
13
In this DSM there are four cells with 1.0 entered in them and
which refer to the four arcs (A-B, B-C, A-D, and D-E) indicating for
each arc a 100% probability of redesign given that a change has
occurred.
bility, which can be easily converted into percentage
format.
It is possible for this computation to yield impossible
results for systems that are not perfectly hierarchical.
An example of this is shown in Figure 14, where element B is now also connected to element E with all other
connections as before. In addition, we have included
probabilities that are less than one that read, for example, as follows: “There is 70% probability that a change
in element A results in a redesign of element B.”
The initial matrix is fine as it stands, but when
squared it yields a sum of 1.7 in cell A-E as shown in
Figure 15. This would suggest that the design of element E is 170% probable to change if a change has
occurred in element A. This situation arises because of
the two different pathways from element A to E, each
of length 2. Clearly a 170% probability is impossible,
as by definition the maximum probability can only be
100%.
In this instance it is easy to make the ad-hoc decision
to truncate this cell to 100% as there exists a pathway
from A to E via D of 100% probability, and such a
truncation is shown circled in the figure. A more interesting case would arise if the A-D-E pathway had
yielded a probability of less than 100%—say 90%. In
this case, ought we truncate to 100%, or to 90%, or to
some other number? This question arises because the
DSM is a high-level abstraction of the underlying system—the DSM of the underlying system would be
much more detailed and actually link together the design parameters in play with much less ambiguity. The
issue is what information is being transmitted along the
path A-B-E or A-D-E as: If it is the same information,
then the maximum change should be 90%, whereas if
it is different information, then the maximum change
might be another amount. Clearly since “a change has
occurred” in A the information being broadcast is omnidirectional and so the crux becomes to what extent the
information is modified by B as opposed to D. We take
the stance that each branch that crosslinks will always
retain whatever is the most important aspect of the
change in A for all downstream elements, and so the
essentially subtractive process of losing information
(reducing visibility) is a context independent one of
losing the least important information first.14 Therefore,
14
The decision to use this definition is only justifiable because
the DSM is an intermediate level abstraction intended to assist in
interpreting architectures, or in a priori optimization of architectures
at an early stage of the design process. For interpretation purposes
since any abstraction implies a loss of detail, this is essentially a
tradeoff that must be desirable to obtain a better feel for the overall
architecture. For design purposes it is probable that the highly detailed
parameterization required to use any other definition would require
so much study that it would not be possible to consider the full range
of possible architectures.
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
49
Figure 13. The reachability matrix of a DSM.
the correct truncation would be to 90%, or in general to
the maximum of the alternative pathways of that length.
This definition of how information is lost in a context-independent manner also affects our hitherto naïve
decision to sum across the successive powers of the
reachability matrix in order to populate the summation
matrix. Instead, in the same way that we truncate multiple pathways of the same length to the maximum of
the alternative pathways, so too is it necessary to truncate multiple pathways of any length to the maximum
of the alternative pathways.
This leads to a final and precise definition of visibility as “the extent to which a change in any one element’s
design information affects any other element by the
clearest possible (single) path irrespective of length,
and making the assumption that information is lost in
the order of least important first irrespective of context.” With this revised definition the computation of
visibility and the companion concept of dependency
becomes a mechanistic chore.
5.2. Interpreting Architectures Using
Scatter Plots of Visibility-Dependence
The architecture of a system yields a visibility-dependency signature that is best appreciated as a scatter plot.
This signature can be described by five generic characteristics: homogeneity, connectivity, layering, relationship laterality, and decompositional cleanliness. These
characteristics are illustrated in the six examples of
Figure 16 and qualitatively discussed below.
Homogeneity: The degree of scatter or dispersion
in the data points illustrates the degree of homogeneity
or heterogeneity in the system. In assessing homogeneity, one needs to exercise caution, as identical data will
only show as one point. A homogenous system is one
where all elements are equally linked—these are “neutral” architectures; i.e., it is difficult for a subset of
elements to dominate the system. Homogenous systems
will therefore tend to be closed topologies—such as 2or 3-dimensional ring/sphere structures.
Connectivity: Not all networks are equally connected, and this is observable by the location of the
center of gravity of the scatterplot. The closer the center
of gravity is to the origin, the lower the degree of
connectivity.
Layering: Multiple tightly clustered groups or horizontal lines indicate that a layered structure exists.
Depending on the degree of connectiveness and topology, this may be layer-cake decomposition or a concentric spherical decomposition. Layering eases
modularization. The topmost layer may only be represented by one data point, and often the number of data
points grows as one descends. If the scatter plot consists
of clustered groups, then it indicates that within each
layer there is a common amount of crosslinking
whereas horizontal lines suggest heterogeneity in
crosslinking. If the DSM has been constructed at a given
level of decomposition, and not had high-level rule
elements added in, these upper rule layers might not be
represented, even though they do exist. These would
represent assumptions that are so basic that they are not
Figure 14. Imperfectly hierarchical system (crosslinked).
50
SHARMAN AND YASSINE
Figure 15. Reachability matrix of crosslinked system.
even mentioned. Such situations typically exist when
there is a great deal of agreement about what is the
dominant design and/or where intangible relationships
have not been inserted into a physical domain derived
DSM. This is discussed further in Section 5.4.
Decompositional Cleanliness: If relatively unilateral relationships dominate the system, then the system
offers the potential to be decomposed into a clean
hierarchical structure with little crosslinking. Assuming
optimal decomposition, the steeper the (negative) gra-
Figure 16. Characteristic types of visibility-dependence signatures.
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
dient of the trend line, the less crosslinking there is. This
is because clean decompositions have few relationships
that cross the decomposition boundaries, and so the
visibility of a given element is minimized. This leads to
a general caution regarding interpreting the scatter
chart, as it is a combination of the intrinsic architecture
of the system and the decomposition that has been
applied. The exception to this caveat is that where a
system has been fully decomposed it can only reveal the
system architecture.
Unilateral and Bilateral Relationships: The extent
to which the network has one-way unilateral relationships as opposed to bilateral relationships will determine the slope of the trend line in the data. This is
because bilateral relationships are essentially “democratic”—the more an element is visible, the more it is
dependent, while unilateral relationships lie along the
orthogonal trend line. Conversely, the slope of the trend
line is a quantifiable measure of the degree of bilateral
versus unilateral relationships in a system. Unilateral
systems can always be resequenced to force relationships below the diagonal, while for a bilateral system
this is not possible as the DSM will be symmetric about
the diagonal.
5.3. Mapping Physical DSMs to Task DSMs
To Obtain Probabilities
The simple binary relationship marks in many process
domain (i.e., task) DSMs skirt the issue of what is being
related between elements, and it is often unreasonable
to drill to the level of detail required to fully populate a
parameter DSM. While there are examples of populating task DSMs with rework probabilities [Browning
and Eppinger, 2002], we suggest that the physical domain DSM is more useful in characterizing product
architectures. This is because most process DSMs only
reveal the design process in use—it is likely to have
been constructed by asking the designers how they
actually design the system rather than by asking them
how else they might design the system. Consequently,
the ability of process DSMs to describe product architectures is somewhat constrained (or biased) by only
having information regarding the design process in
use.15
In contrast, the physical domain DSM is populated
by asking how elements relate to each other in the
architecture (regardless of the design process in use),
and there is normally a far greater understanding of all
15
Caveat: Some distributed approaches to process modeling
yield models based on the fundamental information needs of small
tasks and illuminate numerous alternative approaches to design
[Browning and Eppinger, 2002]. We would like to thank one of the
anonymous referees for pointing this out.
51
the physical dependencies. So, a given product may
have many above-diagonal marks in its physical domain DSM while the process domain DSM has been
reduced to a manageable linear process with relatively
few above-diagonal marks representing a few design
iterations. Similarly, the process domain DSMs tend to
be binary, and direct assessment of rework probabilities
is difficult and unintuitive, while it is relatively easy for
respondents to identify with weightings in a physical
domain. These weightings (typically on a four-point
scale as in Table III) can then be mapped to rework
probabilities and become an indication of the process
architecture, unsullied by the imposition of design assumptions that reduce the probability of rework.16
5.4. Representation of Intangible
Rules/Relationships
Baldwin and Clark [2000] propose that a modular design process has three stages: (1) formulation of design
rules, (2) parallel work on modules, and (3) testing and
integration. The stage-1 relationships control elements
of the design process such as the size, the configuration,
the schedule, manufacturing location, etc. The stage-3
relationships control the testing and integration of the
design. From this proposition it can be seen that the
stage-2 relationships are equivalent to those considered
in the standard physical domain DSM. However, in
order to consider the entire signature of a product
architecture, the elements representing intangible relationships need to be inserted; we refer to them as
stages 1 and 3 of the design process. As an example,
while the analysis of a physical 10 MWe generator will
reveal all stage-2 relationships and their associated
tasks, it may not be possible to directly intuit that the
unit had to be tested (a stage-3 task relationship) or that
there was the task of deciding what power generator
ought to be designed (a stage-1 task relationship).
6. CASE STUDY—GAS TURBINE
GENERATOR SET
A synthetic physical DSM for a generic 10 MWe gas
turbine driven electrical generator set was constructed
by decomposing it into 31 subsystems. The subsystems
initially were listed arbitrarily in the DSM, and then tick
marks denoting material relationship from one subsys16
In this paper, we map Table III dependency strengths to
rework probabilities as follows: 0 dependency strength corresponds
to 0% rework probability, 1 dependency corresponds to 30% rework,
2 dependency corresponds to 60% rework, and 3 dependency corresponds to 90% rework. This mapping is consistent with other DSM
research as described by Smith and Eppinger [1997].
52
SHARMAN AND YASSINE
Figure 17. Physical DSM of gas turbine with manual clusters.
tem to another were inserted.17 At first, these relationships were noted on a binary scale of 0 (no dependency
exists) or 1 (a dependency exists). Next, an explicit
assignment of the relationship strength was performed,
where the tick marks were replaced with a four-point
scale in accordance with Table III. The resultant DSM
is shown in Figure 17. It can be seen from the figure that
the gas turbine generator set is not a fully integrated
product because the matrix is not fully populated.
Therefore, it ought to be possible to manipulate the
DSM to force as many relationships as possible close
to the diagonal and thereby expose the irreducible clusters for further analysis.
6.1. Manual Clustering of DSM
Intuitive manual clustering can yield different results,
depending on the extent to which a single group of
system-wide relationships is emphasized over “good”
clusters. Figure 17 shows a manually clustered DSM
with clusters arbitrarily marked off by borders to emphasize their location and nominal boundaries. After
inspection of the clusters, they were given names to
identify them. Notice how clusters can overlap (e.g.,
17
See Sharman [2002] for further details of the DSM genera-
tion.
turbine island with the core)—in extreme cases they can
become completely embedded.
The identification of a cluster of system wide elements that spans the bottom, or the right-hand side, or
both, is characteristic of these sorts of DSMs. In the
functional (i.e., task) domain, such a system wide layer
would normally equate to the test and integrate tasks
that are performed towards the end of a project sequence. In the physical domain there is no timeline
associated with being in the lower right-hand corner,
and so it is better to term this a “bus.” This bus is actually
termed the “main bus” as system-wide integrating elements need not necessarily be confined to this lower
right area. For example, a weak bus is identified by the
dashed ellipse in Figure 17. Consider also how easy it
is to give exactly the same cluster a different yet equally
meaningful name, and how easy it is to identify different cluster boundaries. This demonstrates the dangers
of manual intervention and motivates the need for some
form of automated clustering algorithms. However, before delving further into automated clustering algorithms, it is worth stepping back and reflecting on the
features seen so far. This allows clarification of the
terminology so as to have a firm foundation for the next
step.
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
6.2. Comparison with Real Architectures
By inspecting the gas turbine we can observe if the
features proposed in Section 4 are in fact present. The
process of identifying potential features improves our
understanding and allows us to recluster the gas turbine
DSM in an improved manner.
The DSM shown in Figure 17 exhibits weighted
strength asymmetric relationships, and this is most evident in the manner in which the bus module is populated. The below diagonal portion of the bus module is
more heavily populated (both when looking at the simple binary existence of relationships and when looking
at the strengths of the relationships) than the above
diagonal portion of the bus module. Under the convention in use this asymmetry indicates that this bus
module is relatively dependent on the remainder of the
gas turbine system rather than the system being dependent on it.
Furthermore, a sequence of five nonbus modular
clusters is identifiable. In this diagram they are given
identifying names: heat and noise; turbine island; core;
53
air clean-up; electrical. The features discussed in the
cartoons are now observable: All but the individual
elements are pinned together and one is pinned to the
main bus module. The pinned heat and noise module
exhibits an auxiliary bus characteristic (outlined by
the dashed oval) but is apparently held away from the
main bus module by the pinned electrical module.
Some of these modules are relatively more populated
(perfect) than others, have different sizes, and exhibit
varying degrees of asymmetry.
6.3. Applying Dimensionality to the Gas
Turbine
It is valid to enquire whether this is the best clustering
arrangement, and, by considering the notion of dimensionality, it can be shown by inspection that the improved solution is better even in the absence of a
codified value system. Exploiting the torosity of the
DSM yields the better manual solution of Figure 18.
This is “better by inspection” as it changes no sequences
within modules but simply adjusts the sequence of some
Figure 18. Better manually clustered DSM.
54
SHARMAN AND YASSINE
of the primitives in the bus module to allow the unpinned electrical module to nestle against the bus module. This obviously reduces the size of any notional
penalty term associated with the relationships denoted
by the auxiliary bus being held away from the main bus.
First, this alternative solution illustrates the important point that in the physical domain there is no reason
why a bus is best parked in the lower right or upper left
corners. Inspection of the literature shows that, irrespective of domain, these are the normal parking locations, and it appears that this is a carryover from process
domain DSMs where there is good reason to prefer this
layout. Exploitation of this parking freedom is possible
once dimensionality is understood. Second, it may still
be valid to use the normal parking convention if the
number and arrangement of modules permits it. This is
because it is easiest to inspect, and because the physical
domain often maps closely to the task domain so arranging it in this way eases the process of comparison. This
point is expanded upon by Sharman, Yassine, and Carlile [2002], regarding interdomain mapping. Third,
many runs of the Thebeau clustering algorithms failed
to reveal this clustering solution. This suggests that the
underlying clustering heuristics are less rich than the
problems to which they are being applied and that, to
develop better clustering algorithms and metrics, it is
necessary to fully understand the principles of clustering and the language of representation.
6.4. Expanding the DSM To Include
Stage-1 and -3 Relationships
Until now, to keep the analysis simple, the gas turbine’s
DSM has represented the relationships between only
the 31 tangible (physical) elements, representing stage
2 of the design process. However, as mentioned in
Section 5.4, we need to insert the elements and relationships that represent intangible relationships (i.e., stages
1 and 3) in order to consider the entire signature of a
product architecture. This insertion process is generally
described in Baldwin and Clark [2000]. However, an
elaborate explanation of the insertion procedure for the
gas turbine can be found in Sharman [2002].
The insertion of stages 1 and 3 resulted in 14 new
elements introduced into the DSM. Eleven of these new
elements represent the stage-1 tasks of formulating the
design rules, and these are placed first in the sequence,
and three represent the stage-3 elements of testing and
integrating and are placed last in the sequence. These
14 elements are our interpretation of the missing elements of the design process of a generic generator set
together with our interpretation of the overall relationships. Stage-1 elements comprise three major steps:
determine scale of product, apply scale dependent rules
to determine decomposition, and apply decomposition
dependent rules to determine module design rules.
Stage-3 elements are: component, assembly, and full
tests. After the insertion of stages 1 and 3, the DSM will
be represented by its expanded 45-element version as
shown in Figure 19.
6.5. Gas Turbine Molecular Diagram
In an attempt to represent the architecture in a more
intuitive manner a molecular diagram was created. The
obvious clusters were manually identified in the DSM,
as far as possible based on Figures 17, 18, and 19, but
without overlaps (i.e., unpinned) to ease the task of
computing relationships.18 Then, in order to get a feel
for molecule size and connectivity, the summed intercluster relationships are shown in the collapsed 18-element DSM of Figure 20.
Ignoring the singletons, it is then possible to sketch
out a “molecular” hierarchy diagram of the gas turbine
where circle size indicates the sum of the hidden relationships (i.e., the on-axis score), and line size and
arrow size indicate direction and strength of visible
relationships as shown in Figure 21.
The closed 3-dimensional form of this molecular
diagram illustrates why the DSM clustering algorithms
find it difficult to get traction, and why planar hierarchical “organization diagrams” are insufficiently rich
representations. This naïve molecular diagram is sufficiently simple to use as a visual representation when
discussing the results of this analysis, yet not so simple
as to misrepresent the complexity of the underlying
structure. As such, it is a meaningful aid for determining
architectural decomposition with people who do not
understand the actual product complexity, and who
might desire to impose counterproductive artificially
simple solutions that would impair the inherent architectural value. For these purposes this molecular diagram is an improvement over the DSM representation
of Figures 17 and 18, which can easily be misinterpreted as Figure 3 illustrated and has now been shown
in this case. Nevertheless, the DSM is still required so
that the technical expert can create the correct molecular diagram to use as a communications tool to illustrate
the issues to the nonexpert.
18
A short example describes how Figure 20 was generated from
Figure 19, and how this then gives rise to the molecular diagram of
Figure 21. The four elements in the upper left of Figure 19 are all
associated with determining the scale of the product (i.e., stage 1a),
and all relationships are populated with a weighting of 2. Thus the
corresponding entry for cell (1a, 1a) in Figure 20 is 12 × 2 = 24 (i.e.,
ignoring the on-diagonal) and the corresponding entry for (1a, 1b) is
(9 × 2) + (3 × 1) = 21. Ultimately these entries control either the size
of a molecule (e.g., “24”—written in the circle) or the strength of a
link (e.g., “21”—not written in the arrow) in Figure 21.
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
55
Figure 19. Expanded gas turbine DSM including stages 1 and 3.
6.6. Gas Turbine System Signature and
Architectural Hierarchy Diagram
Calculating visibility revealed the architectural signature of the scatter plot of visibility-dependency shown
in Figure 22.19 Bearing in mind the characteristics
discussed in the previous section, this signature may be
categorized as shown in Table IV.
The seven elements having dependencies of ~5–
10% (Group A in Fig. 22) are all associated with design
tasks that occur prior to generating preliminary designs,20 while all other elements have dependencies of
19
This signature calculation used probabilities of 90%, 60%,
30%, and 0% to correspond to relationships of strength 3, 2, 1, and 0.
In general, we observe that any architecture that is recursive is highly
sensitive to the probability and topology of any feedback loops.
20
They are the identification of the power rating, the load
market (peaking, base load, etc.), other customer requirements, cycle
selection, time to market, trade studies, and configuration.
~40–70% (Group B in Fig. 22). Thus these seven tasks
seem to have an order of magnitude greater leverage in
the design process than almost anything else.
In this system performance will greatly depend on
the extent to which the human designers are able to a
priori determine the optimal system decomposition and
design points (by defining the correct element and
inter-element feedback parameters) prior to their emergence in linked models and full scale testing. More
simply, the performance of the design process, and the
performance of the resultant gas turbine, are highly
dependent upon the designers choosing the parameters
of Group A wisely on their first pass. Once the resultant
parameters have cascaded into Group B, it becomes
difficult to change any one parameter without having a
shower of undesired knock-on effects to other parameters.
56
SHARMAN AND YASSINE
Figure 20. Collapsed 18-element DSM from the 45-element version.
Figure 21. Molecular hierarchy diagram for gas turbine.
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
57
Figure 22. Gas turbine architecture visibility-dependency scatter plot. The marks at (0, 0) are from unused (unconnected) elements.
Our program has the capability to analyze visibility propagation in a 50-element DSM, and only 45 are used on this occasion.
This particular gas turbine example is available for inspection at http://www.staff.uiuc.edu/~yassine/publications.htm together
with the program for performing the visibility-dependency calculations.
This paper only addresses characterization and representation and is not primarily intended to discuss
analysis; however, each representation has different
drawbacks for analysis. An example of this is that while
the scatter plot gives an indication of an element’s
importance, it does not give an indication of the pathway by which the element affects others. So, inspection
of the V-D scatter plot does not reveal that the elements
of Group A are strongly linked to those of Group B2
(which are the core of the gas generator) and less
directly, but similarly strongly to those of Group B1
(primarily verification and validation) and that this is
an important way of directly and indirectly influencing
the performance of the system as a whole. Instead it is
necessary to turn to the original DSM or the molecular
diagram to see these links.
In the visibility-dependency scatter plot three lines
are shown: the 1:1 slope, and the linear and quadratic
trend lines. Analysis based on points’ position compared to these trend lines is superficial; however, they
do give a quick indication of which are the absolutely
and relatively important nodes in the architecture.
It is interesting to note that more simplistic representations and/or analysis underestimate both the homogeneity of coupling and the extent of the coupling in
the generator set. Thus it would have been easy to
underestimate how easily change propagates through-
out the structure irrespective of what is the initiating
element. In the case of this gas turbine the implication
is that beyond group A there are few easy fixes or
opportunities for penalty free cost reduction as everything is highly connected.
7. CONCLUSION AND FURTHER WORK
In this paper, we have introduced the basic syntax and
semantics for scrutinizing a DSM in order to characterize the architecture of a complex system. We have
also demonstrated how simple building blocks (i.e.,
DSM constructs) were helpful in analyzing the more
complex architectures, such as that of the generator set.
The paper demonstrated why it is difficult to arrive at
automated clustering algorithms without understanding
the implications of modularity and modularization in
terms of path dependencies and dimensionality. By
using the concepts of visibility and dependency we
were able to describe the fundamental characteristics of
a range of architectures that span the continuum from
modular to integrated architectures in a unified quantifiable manner that allows for objective functions to be
built on a fundamentally sound basis. We also were able
to show how multidimensional molecular diagrams can
be drawn from DSMs, to serve as an intermediate level
of abstraction that shields the nonexpert from the details
58
SHARMAN AND YASSINE
Table IV. Characterization of the Gas Turbine Architectural Signature
whilst still giving them sufficient information to be able
to participate meaningfully. Each of these techniques
has advantages and disadvantages as outlined in Table
V. Ultimately each of these techniques merely attempts
to represent the same underlying reality, and each gives
up some information in order to better convey other
information.
There are several limitations intrinsic to this approach, each of which is based on either an assumption
or a simplification. First, it does not drill to the parameter level of detail. Therefore, there is an implicit assumption that all parameters are, to some extent,
additive in calculating gross visibilities. Second, the
conversion of relationship strengths to probabilities
greatly simplifies the parameter level situation. Third,
the population of the full stage-1, -2, and -3 DSM
assumes that stage-2 product (i.e., physical) domain
DSM is isomorphic with stage 2 task domain DSM.
The research currently being undertaken into parameter-level interactions [e.g., Clarkson and Hamilton, 2000] will, in time, answer questions one and two.
In order to explore the third assumption, take a given
product that has been designed by a given process and
explore what alternative processes might have been
possible, and compare the resulting signatures with
each other, and with the intrinsic signature.
Within characterization the natural extensions are to
create quantitative metrics (such as average connectivity—the mean of visibility and dependency; homogeneity—the standard deviation around the average
connectivity; laterality—the slope of the best-fit linear
trend line; layering—the number of discrete groups that
exist; ratio analysis of visibility:dependency21; etc.) and
then explore a library of existing product DSMs
datasets to observe what signatures exist “in the wild.”
Once a library of datasets has been characterized, the
meta-level implications of the results should be evaluated. Another obvious extension of characterization is
to automate the process of creating molecular diagrams
and explore the sensitivity of the resultant diagrams to
tuning of the control parameters. Then conduct research
into whether and to what degree users can usefully
incorporate molecular diagrams into their decisionmaking processes.
Extensions to this work fall into three classes: first,
exploring the extent to which the limitations noted
above and the underlying assumptions are justified;
second, looking in greater depth at the characterization
problem itself; and, third, proceeding beyond characterization into analysis. Other extensions beyond this
characterization work center on architectural optimization. Work to date [Baldwin and Clark, 2000] has emphasized extreme modularity whereas this technique
may allow integrated and semiintegrated architectures
to be analyzed. For example, for a given architecture
explore how societal value might be optimized and then
explore to what extent intrinsically nonhierarchical architectures affect the optimization strategy for societal
value. Following on from this, take an architecture that
is too large to be created by a single actor. For this,
explore how actor value diverges from societal value
and how the resultant tension between societal value
creation and actor value capture lead to pressures to
modify the product architecture. Explore how the presence of multiple actors in multiple nodes leads to architectural evolution in time as successive versions of the
21
Trials with ratio analysis suggest that this may be a suitable
method for differentiating fine differences between otherwise similar
architectures.
CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES
59
Table V. Applicability of Each Technique
product are released and compare this with case studies
of architectural evolution.
REFERENCES
C. Alexander, Notes on the synthesis of form, Harvard University Press, Boston, MA, 1964.
C.Y. Baldwin and K. Clark, Design rules: The power of
modularity, MIT Press, Cambridge, MA, 2000.
T. Browning, Applying the design structure matrix to system
decomposition and integration problems: A review and
new directions, IEEE Trans Eng Management 48(3)
(2001) 292–306.
T. Browning, Process integration using the design structure
matrix, Syst Eng 5(3) (2002), 180–193.
T. Browning and S.D. Eppinger, Modeling impacts of process
architecture on cost and schedule risk in product development, IEEE Trans Eng Management 49(4) (2002), 428–
442.
P. Clarkson and J. Hamilton, “Signposting,” a parameterdriven task-based model of the design process, Res Eng
Des 12 (2000), 18–38.
T. Dwyer, Three dimensional UML using force directed layout, Conf Res Practice Inform Technol, 2001, Vol. 9.
C. Fernandez, Integration analysis of product architecture to
support effective team co-location, SM Thesis (SDM),
Massachusetts Institute of Technology, Cambridge, MA,
1998.
M. Fowler and K. Scott, UML distilled, Addison Wesley, New
York, 2000.
J. Hartigan, Clustering algorithms, Wiley, New York, 1975.
A. Kusiak, Engineering design: Products, processes and systems, Academic, San Diego, 1999.
A. Kusiak and C. Huang, Development of modular products,
IEEE Trans Components, Packaging Manuf Technol Part
A 19(4) (1996), 523–538.
R. Mantripragada and D. Whitney, The datum flow chain: A
systematic approach to assembly design and modeling,
Res Eng Des 10(3) (1998), 150–165.
D. Montgomery, Introduction to statistical quality control,
Wiley, New York, 1996.
G. Moore, Crossing the chasm: marketing and selling hightech products to mainstream customers, Harper Business,
New York, 1999.
P. O’Conner, Practical reliability engineering, Wiley, Chichester, UK, 1991.
K. Otto and C. Wood, Product design: Techniques in reverse
engineering and new product development, Prentice Hall,
Upper Saddle River, NJ, 2001.
G. Pahl and W. Beitz, Engineering design: A systematic
approach, Springer-Verlag, New York, 1999.
T. Pimmler and S.D. Eppinger, Integration analysis of product
decompositions, DE-Vol. 68, Design Theory and Methodology DTM 94, ASME, New York, 1994.
R. Sanchez and J. Mahoney, Modularity, flexibility, and
knowledge management in product and organization design, Strategic Management Journal 17 (1996), 63–76.
D. Sharman, Valuing architecture for strategic purposes, SM
Thesis (SDM), Massachusetts Institute of Technology,
Cambridge, MA, 2002.
D. Sharman, A. Yassine, and P. Carlile, Architectural optimization using real options theory and dependency structure
matrices, Proc ASME 28th Des Automat Conf, DAC34119, Montreal, Canada, 2002.
Z. Siddique and D. Rosen, Product platform design: A graph
grammar approach, Proc ASME Des Eng Tech Conf, Las
Vegas, NV, DETC99/DTM-8762, 1999.
60
SHARMAN AND YASSINE
R. Smith and S.D. Eppinger, Identifying controlling features
of engineering design iteration, Management Sci 43(3)
(1997), 276–293.
M. Spinner, Improving project management skills and techniques, Prentice-Hall, Englewood Cliffs, NJ, 1989.
D. Steward, The design structure system: A method for managing the design of complex systems, IEEE Trans Eng
Management 28 (1981), 71–74.
R. Thebeau, Knowledge management of system interfaces
and interactions for product development processes, SM
Thesis (SDM), Massachusetts Institute of Technology,
Cambridge, MA, 2001.
E. Tufte, Visual display of quantitative information, Graphics
Press, Cheshire, CT, 1983.
K. Ulrich and S.D. Eppinger, Product design and development, McGraw Hill, New York, 2000.
J. Warfield, Binary matrices in system modeling, IEEE Transactions on Systems, Man, and Cybernetics 3 (1973), 441449.
D. Whitney, Why mechanical design cannot be like VLSI
design, CTPID Working Paper, Massachusetts Institute of
Technology, Cambridge, MA, 1996.
T. Yu, A. Yassine, and D. Goldberg, Genetic algorithm for
developing modular product architectures, Proc ASME
15th Int Conf Des Theory Methodol, 2–6 September 2003,
Chicago.
A. Zakarian and G. Rushton, Development of modular electrical systems, IEEE Trans Mechatron 6(4) (2001), 507–
520.
David Sharman was born in the United Kingdom in 1966 and became a naval officer on leaving school.
He read a BEng(Hons) in Weapons Systems Engineering at RNEC Manadon from 1986 to 1989 and served
in ships and submarines worldwide. In 1991 he joined the Royal Dutch/Shell group, where he worked as
a production engineer in the North Sea and Venezuela. After setting up Shell’s operations in Argentina he
completed an MSc in Management & Engineering at MIT in 2002 and is interested in the design and
operation of complex systems, technology strategy, and the technical/commercial interface. He is a
Member of the IEE and the IMechE, and has previously contributed papers to journals or conference
proceedings of the SPE, ICAS, and ASME.
Ali Yassine is an Assistant Professor at the Department of General Engineering at the University of Illinois
at Urbana-Champaign (UIUC) and the director of the Product Development Research lab. He teaches a
graduate class in Systems and Entrepreneurial Engineering and an undergraduate class in Operations
Research. His research involves managing the development process of complex engineering systems,
design process modeling, and IT-enabled concurrent engineering. Prior to joining UIUC, Professor Yassine
was a research scientist at the MIT Center for Technology, Policy and Industrial Development (CTPID)
from 1999 to 2002. Ali’s publications have appeared in Management Science, Research in Engineering
Design, IEEE Transactions on Engineering Management, Concurrent Engineering Research & Applications (CERA), and several other international journals and conference proceedings. He also consulted on
numerous occasions for the automotive (Ford Motor Company) and telecommunications (Global One)
industries in areas of decision analysis and product development management. Dr. Yassine received the
B.E. degree in Mechanical Engineering in 1988 from the American University of Beirut. He received the
M.S. and Ph.D. degrees in 1989 and 1994 in Industrial and Manufacturing Engineering from Wayne State
University in Detroit, Michigan. He is a member of INFORMS, ASME, and PDMA.