Regular Paper Characterizing Complex Product Architecturesay11/Complex-Architecture.pdf ·...

Characterizing ComplexProduct ArchitecturesDavid M. Sharman1 and Ali A. Yassine2, *

1Massachusetts Institute of Technology, Cambridge, MA 02139

2Department 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 revisionsDOI 10.1002/sys.10056

ABSTRACT

Due to the large-scale nature of complex product architectures, it is necessary to developsome 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 describingproduct architectures: (a) the Dependency Structure Matrix (DSM), (b) Molecular Diagrams(MD), and (c) Visibility-Dependency (VD) signature diagrams. Each method has its ownlanguage (and abstraction), which can be used to qualitatively or quantitatively characterizeany given architecture spanning the modular-integrated continuum. A consequence of ab-straction is the loss of some detail. So, it is important to choose the correct method (andresolution) to characterize the architecture in order to retain the salient details. The proposedmethods are suited for describing architectures of varying levels of complexity and detail. Thethree methods are demonstrated using a sequence of illustrative simple examples and acase-study analysis of a complex product architecture for an industrial gas turbine. © 2003Wiley 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

The first step in any analysis is description, and latersteps often include elements of comparison, which rely

upon the ability to describe. However, describing com-plex product architectures poses essential problems asthey tend to be large scale, heterogeneous, and interdis-ciplinary.

Because of the large scale of complex architectures,it is necessary to use some form of abstraction in orderto be able to grasp the structure of the whole. A conse-quence of abstraction is the loss of detail, and it isimportant to choose the correct resolution to view the

Regular Paper

*Author to whom all correspondence should be addressed (e-mail:[email protected]).

Systems Engineering, Vol. 7, No. 1, 2004© 2003 Wiley Periodicals, Inc.

35

architecture so that salient details are retained. Unfor-tunately, a characteristic of complex architectures is thatthey tend to be heterogeneous—they are not merelyrepetitive large-scale structures—and thus the salientdetails in one area of the structure may only emerge ata level of detail that is too great a resolution for anotherarea. This has led to many different schemes for por-traying complex architectures each of which allowsvariable levels of resolution, depending on the relativeimportance of nuances of the structure (e.g., hierarchydiagrams, object-oriented descriptions, dependencystructure matrix, cause and effect diagrams, flowcharts,etc.). While these are helpful, they tend to be specializedin their use, and it is difficult to use them as a descriptivetechnique for interdisciplinary analysis of complexproducts, or where individual products integrate multi-ple disciplines (the typical problems being at the inter-face of software—hardware or static—processinterface).

This paper proposes and describes three differentways to represent complex product architectures. Eachseems best suited to a different level of resolution andeach has proven useful in analyzing a particular case ofa complex product. What links them together as de-scriptive models is their reliance on manipulating thedata encoded in a Dependency Structure Matrix (DSM)in order to arrive at the desired abstraction. The strengthof these three approaches is that they appear to beproduct-type independent and are able to cope withheterogeneous architectures. To varying extents each isamenable to use in both a qualitative and quantitativemanner. The three representation methods are:

1. Micro-level DSM cartoons and related language2. Intermediate level molecular diagrams3. Macro-level visibility-dependence signature dia-

grams and related characteristics

The category of manmade products known as com-plex systems are often decomposed into a number ofsimpler sub-systems (i.e., modules) that can be control-led independently, and whose collective individual be-haviors yield the performance of the original complexsystem. Proper decomposition of design developmentinto modules is concerned with assigning into the samemodule development tasks that are anticipated to re-quire high problem-solving interaction, while assigningto different modules the tasks that require low problem-solving interaction.

Even though decomposition of the development ef-fort normally reduces the technical complexity of de-velopment, it creates a serious managerial challengedue to the complex web of dependencies and interac-tions between the modules, which require careful man-

agement. Therefore, analysis of product decomposi-tions provides valuable insights into the structure of theproduct and the choice of architecture. Ulrich and Ep-pinger [2000] define product architecture as the schemeby which the decomposed elements are arranged inmodules. The less interacting these modules are, themore modular the product architecture is.

Modularity as a strategy can be employed for differ-ent reasons. In the right circumstances it allows in-creased product or organizational variety [Ulrich andEppinger, 2000] increased rates of technological orsocial innovation [Baldwin and Clark, 2000]; reducescosts through reuse; more sharply defines the opportu-nities for market dominance through interface capture[Moore, 1999]; and the increased specialization at firmlevel may allow more flexible response to environ-mental change [Sanchez and Mahoney, 1996]. Butmodularity has drawbacks. In its extreme form theintermodule interfaces must allow change to occurwithin modules without adversely affecting inter-module working, and this is beneficial only if the choiceof element division into modules is optimal, if all ele-ments are divided into unique modules, and if all inter-module relationships are then completely described ininterface descriptions that also fully describe the emer-gent system-level characteristics. Such a harmoniousstate only occurs when designers well understand theproduct so that they are able to describe completely andclearly optimal interface rules, while premature modu-larization adversely affects the system-level trade-space.

This paper uses the Dependency Structure Matrix(DSM) as the underlying model for representing aproduct’s architecture. Direct inspection of the DSMitself is one valid way of interpreting the product’sarchitecture. This tends to be of most use when theproduct is both of relatively small scale and has internalrelationships of low complexity. However, as we showin this paper, it does not take much of an increase incomplexity for direct inspection of DSMs to becomeunsatisfactory as a way of grasping the overall architec-ture. Similarly, although not discussed at length, agrowth in the scale of a product to more than a fewhundred elements makes it difficult to read a DSMdirectly. Nevertheless, there seems no better discipline-independent way of understanding the micro architec-ture of a product than to inspect the DSM.1

As scale and complexity increase, it becomes moresensible to observe where the levers of control are in theproduct’s architecture. This leads us to the twin notions

1The micro-architecture of a product is the architecture whichone sees at a relatively high level of (i.e., detailed) resolution such asthat used to see down through three or more layers of abstraction (e.g.,product, subsystems, modules, and then elements/components).

36 SHARMAN AND YASSINE

of visibility and dependency in an architecture andconsideration of these suggests that all architecturesposses a characteristic visibility-dependency signature.This appears a useful way of viewing large-scale com-plex systems at a macroscopic level, and we show howto display these signatures.

A drawback with visibility-dependency signaturesand DSMs is that they are not always easily appreciatedat first glance by an untrained or nontechnical audience.For this reason we have developed the intermediatelevel representation that we term the molecular dia-gram. At present this is a very flexible and somewhatarbitrarily crafted device and as such is necessarily lessmature, but nevertheless initial anecdotal responsesfrom users has been that it enables them to “get it”sufficient to be able to contribute meaningfully to highlevel discussions and without imposing arbitrary solu-tions. Each of these three techniques has been deliber-ately chosen to address the representation problemsposed by complex products. That is, they are capable ofcoping with large-scale systems spanning multiple dis-ciplines and possessing areas of differing levels ofcomplexity.

The rest of the paper proceeds as follows. In the nextsection we describe some different pictorial repre-sentation systems used in engineering and discuss theirrespective limitations. Then we introduce the Depend-ency Structure Matrix (DSM) method in Section 3.Following this, Section 4 introduces the fundamentalanalysis techniques used in the DSM to characterize aproduct’s architecture and identify modular clusters,and closes by introducing the closely related topic ofmolecular diagrams. Section 5 describes visibility anddependency and how these are affected by whetherarchitectures are hierarchical or recursive, and binary ornonbinary; as well as other generic and quantifiablecharacteristics of architectural signatures. Section 6applies this to the case study of a gas turbine generatorset, and Section 7 contains the conclusions and notesregarding further work.

2. PICTORIAL REPRESENTATION INENGINEERING

The engineering community has a long tradition ofbuilding models to represent various engineering arte-facts. These models range from simple 2-dimensionalfreehand sketches to complex 3-dimensional CADmodels.2 Moreover, these models range in their level ofabstraction from highly abstract (e.g., mathematical

models) to the less abstract (e.g., physical prototypes).However, in this section we will restrict our discussionto a special type of engineering models: visual (orpictorial) models. A pictorial model provides sufficientunderstanding of the “thing” being modeled and visualaccess to the subtle and the complex. The key is toprovide an “honest” portrayal of complexity and not thecomplication of the simple [Tufte, 1983].

Table I provides a nonexhaustive list of such visualmodels, which are extensively used within the engineer-ing community. Even though these models may servedifferent purposes and be employed at different timeswithin the engineering design process, they all share acommon goal of visually displaying quantitative infor-mation, which is otherwise not as easily accessible tothe engineer or analyst.

Investigating existing engineering models, to assesstheir utility in describing and analyzing product archi-tectures, we observed that many, such as CAD modelsand function diagrams, are specific to either a producttype, or to an engineering discipline, and do not enableanalysis between products or across disciplines. Anexample is that a CAD drawing of the mechanicallayout of a PC provides no feel for the importance orcomplexity of either the electronic design or the soft-ware. Although function drawings can provide cross-discipline information, they have great difficulty inconveying nonhierarchical information as we discussbelow.

In engineering design, for example, CAD models ofparts or assemblies are the norm nowadays. However,these models, even though extremely useful for productrealization, are not as useful for analyzing architecturalproperties. A more relevant model is a function diagram[Otto and Wood, 2001]. The technique starts with cre-ating a function structure for the product under consid-eration.3 This is followed by clustering or grouping thesubfunctions into modular chunks. The method is use-ful in developing modular product architectures for newproducts rather than analyzing the architecture of exist-ing products. Furthermore, it relies on an undirectedsearch 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 forthe development of modular products. Even thoughthese methods utilize either a matrix form or a networkrepresentation to carry out the modularity analysis, theytend to be more helpful for analysis rather than repre-sentation in comparison to DSM models. Furthermore,most of these methods rely on mapping the functional2A model is an abstraction of an object (e.g., a designed artifact),

a system (e.g., an automotive transmission), or a process (e.g., theprocess of designing a shaft), and is typically constructed for repre-sentation and analysis [Kusiak, 1999].

3A function structure is an input–output diagram of what aproduct does [Otto and Wood, 2001].

CHARACTERIZING COMPLEX PRODUCT ARCHITECTURES 37

decomposition of the product to the product (physical)architecture. For example, Pahl and Beitz [1999] di-rectly link the definition of modules to functionality(i.e., basic, auxiliary, special, and adaptive). A modulein this way is the physical realization of a function, andthe whole interface problem (between physical compo-nents) is not addressed. On the other hand, this paper(i.e., DSM models of representation) does not addressitself to the function/form relationship (i.e., does notrequire a functional decomposition as a prerequisite formodularity analysis) and rely merely on the physicalcomponents composing the product, and the interactionamong them, to describe and characterize productmodularity.

Finally, other existing methods are essentially hier-archical (e.g., IDEF models, functional diagrams, andhierarchy diagrams), an assumption that can be easilyviolated in complex architectures. This is particularlytrue of systems with relatively high-energy interactions[Whitney, 1996], where the performance of the systemas a whole is critically dependent upon interactionsbetween subsystems. This is most evident in highlyintegrated products such as in the automotive and aero-space sector. That a nonhierarchical system exists iseasy to appreciate by attempting to draft a functiondiagram for the system—and observing that there aremany possible alternate decompositions into superfi-cially hierarchical structures, each of which loses manyof the essential interactions.

In this paper, we use a matrix representation for thecapture and display of product architecture [Pimmlerand Eppinger, 1994]. The model is called the Depend-ency Structure matrix (DSM). In a DSM model, theelements within a system (i.e., components and subsys-tems) are listed and the relationship among them isvividly displayed. This matrix representation is com-pact, easily understood, and it allows us to developrigorous search and computation algorithms to findcertain architectural features and optimal module con-figurations [Browning, 2001, 2002].

3. AN OVERVIEW OF THE DEPENDENCYSTRUCTURE MATRIX (DSM)

The Dependency Structure Matrix (DSM)4 is an infor-mation exchange model which allows managers to rep-resent important system (or task) relationships in orderto determine a sensible arrangement (or sequence) forthe system (or project) being modeled. In this section,we describe the basic DSM method and how it can beused to model product architectures (or projects), deter-mine the dependency structure between the systemelements (or information flows within a project), and tomore accurately identify a product (or project) architec-ture.

A DSM is a matrix representation of a directedgraph. The nodes of the graph correspond to the columnand row headings in the matrix and the arrows corre-spond to the marks inside the matrix.5 For example, ifthere 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 haveno significance and are normally blacked-out.

A systematic taxonomy and a quantification schememay also assist in the analysis by categorizing types ofinteractions among DSM elements and associating anappropriate weight to each. Tables II and III representthe classification of interactions and an example of aquantification scheme proposed by Pimmler and Eppin-ger [1994] as modified by Sharman [2002].6

There are four different types of DSM models ap-plied to various levels of abstraction [Browning, 2001].The Task (or process domain) DSM model describes the

Table I. Visual Models in Engineering

4DSM also stands for Design Structure Matrix—in this paperthe two meanings are synonymous. 5There are different ways of building a DSM, and two differentsign conventions in use. In this paper we place feed forwards belowthe diagonal, i.e., counterclockwise. For a full description on theseissues, refer to the DSM website at http://www.DSMweb.org. 6The four-point scale shown here was the minimum requiredin practice to reliably discern clusters. Finer scales seem likely to beof little benefit as other factors such as uncertainty in estimating thetrue value become dominant.


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


interactions between design tasks. A variation of thisDSM type is the Parameter DSM, which takes a deeperlook into the tasks by decomposing them further intodesign parameters delivered by each task. A parameterDSM describes how does the parameters influence eachother and in what order they should be determined tominimize guessing and feedback. Thus, as with taskDSMs, partitioning is the commonly used analysis tech-nique for streamlining the sequence of parameter cal-culations. The third DSM type is called Team (ororganizational domain) DSM. This DSM model is usedfor organizational analysis and team formations basedon the intensity and frequency of information flowamong various organizational entities (i.e., develop-ment participants). Finally, the Component (or physicaldomain) DSM documents interactions between ele-ments of a complex system architecture. For the lattertwo DSM models, clustering is typically used to rear-range the DSM and identify improved team formationsor 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 theinputs and outputs, respectively, for that task. For ex-ample, in Figure 1(a), B feeds C, F, G, J, and K, whileE, F, and L feed D. If there is a time sequence associatedwith the position of the elements in the matrix, then allmarks above the diagonal are considered feedbackmarks. Feedback marks correspond to required inputsthat are not available at the time of executing a task. Inthis case, the execution of the dependent task will bebased on assumptions regarding the status of the inputtasks. As the project unfolds, these assumptions arerevised in light of new information, and the dependenttask is reexecuted if needed (i.e., design iteration).

The matrix can be manipulated in order to eliminateor reduce the feedback marks. This process is calledpartitioning [Steward, 1981]. When this is done, a trans-parent structure for the project starts to emerge. We cansee which tasks are sequential, which ones can be donein parallel, and which ones are coupled or iterative [seeFig. 1(b)]. In partitioning, the main objective is to movethe feedback marks from the above the diagonal tobelow the diagonal, given that the DSM elements aretasks to be executed. However, when the DSM elementsare people in charge of these tasks, system elements, orcomponents of a larger system, then we have a differentobjective for arranging the DSM. The new goal be-comes finding subsets of DSM elements (i.e., clustersor modules—sometimes also termed chunks) that aremutually exclusive or minimally interacting. This proc-ess is referred to as clustering. In other words, clusters

contain most, if not all, of the interactions (i.e., DSMmarks) internally and the interactions or links betweenseparate clusters is eliminated or minimized [Fernan-dez, 1998]. In which case, the blocks become analogousto team formations or independent modules of a system(i.e., product architecture). Furthermore, in this setting,marks below the diagonal are synonymous to marksabove the diagonal and they represent interactions be-tween the teams or interfaces between the modules. Asan example, consider the DSM in Figure 2(a). Theentries in the matrix represent the frequency and/orintensity of communication exchanged between thedifferent development participants, represented by per-son A, person B, et al.

As can be seen in Figure 2(b), the original DSM wasrearranged to contain most of the interactions withintwo separate blocks: AF and EDBCG. However, threeinteractions are still outside any block (i.e., team) andconstitute the points of interaction/collaboration be-tween the two teams. An alterative team arrangement issuggested in Figure 2(c). This arrangement suggests theforming of two overlapping teams (i.e., AFE andEDBCG) where one person (i.e., E) belongs to bothteams and may act as a liaison person.

3.2. Clustering Algorithms

Early clustering algorithms and underlying principlesare described in Alexander [1964]. These algorithmswork in either a top-down or a bottom-up manner, eitherby cleaving along the line of least resistance or byaggregating along the path of greatest return. In eithercase, the relevant metric is some function of the numberof linkages that cross a partition boundary. In Alexan-der’s work, this objective function was implementedwith a simple hill climbing search strategy whereby thesystem either was successively partitioned into ever-smaller sets or successively aggregated into ever-largersets, one element at a time. Further details of clusteringalgorithms and a wide range of applications can befound in Hartigan [1975].

Fernandez [1998] and Thebeau [2001] used a similarapproach to Alexander’s bottom-up aggregation. Eachelement is placed in an individual set and bids evaluatedfrom all the other sets (clusters). If any cluster is able tomake a bid that is better than the current base case, thenthe element is moved inside the cluster. The objectivefunction is therefore a tradeoff between the costs ofbeing inside a cluster and the overall system benefit.

Existing clustering algorithms [e.g., Fernandez,1998; Thebeau, 2001] were applied to the generator setexample of Section 6. As a result, we observed that thesealgorithms were unable to handle complex integratedarchitectures. In investigating the underlying reasons


for this difficulty, we developed a language to describearchitectures and then were able to observe and describecomplexity issues such as path dependency, dimension-ality, and boundary definition that are of fundamentalimportance in handling non-trivial architectures. Thisallows us to explain why DSMs in general, and cluster-ing algorithms in particular, experience difficulties inhandling architectures of the nature illustrated in Figure3, and the caution that must be taken in interpretingDSMs of such complex architectures.

4. DSM BUILDING BLOCKS;ARCHITECTURAL/MOLECULAR DIAGRAMS

In this section, we define the basic syntax and semanticsfor scrutinizing DSMs in order to characterize the ar-chitecture of a complex system. We introduce the notionof a product being composed of elemental chunkswhich can be organized into modules. Chunks can beattached to each other in different ways, and, when achunk becomes the carrier for other chunks, it is termeda bus. We further explain the concepts of pinning andholding away that can cause weak buses to becomestranded away from the main bus. We then go on todiscuss issues around the process of arranging productarchitectures including the notion of path dependencyin clustering, dimensions, and topology.

The analysis proceeds using simplified (i.e., car-toon) architectures that are described using DSMs,physical schematics, and basic architectural diagramsin order to introduce and define the terminology re-quired to develop the underlying constructs with the

minimal amount of complicatedness. These simple con-structs will be used later in the paper to analyze morecomplex product architectures and are the basis fordeveloping 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 afifth, and three of these four connections are of equalstrength. This is shown on the left as a physical sche-matic that can be thought of as representing a flow ofmass, energy, information, or force/geometrical con-straint between the parts.

This situation may be visualized as E being someform 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 aresymmetrical; i.e., part A depends on part E in the sameway 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 ordependence), and a large “X” represents a strong rela-tionship. To the right of the DSM, a more conceptualarchitectural diagram that represents the same situationis shown [Fig. 4(c)]. This third diagram [Fig. 4(c)] canbe drawn in any orientation as the relationships aresymmetrical; thus at this stage no value should beassigned to any convention that chooses to draw part Eabove rather than below or to the side.

A part is the smallest possible decomposition ofsomething while a chunk or element could be assem-

Figure 3. Conceptual illustration of the problem of depicting and interpreting complex architectures.


blies in their own right. For this reason strict terminol-ogy should differentiate between primitive elements(i.e., parts) or higher-level elements (i.e., chunks). Weterm a bus as being “simple” when it is a primitiveelement.

In Figure 5, we introduce more relationships be-tween parts. In this instance, the pair of parts A and Bis related symmetrically to each other as well as eachpossessing an equal relationship with part E. A similarstructure can be seen in the pair of parts C and D. In theDSM, we define this pairing as being a modular clusterand denote it by the (two letter) description “ModuleSS” and “Module TT.”7

The significance of being a modular cluster is thatall the parts within the module possess the same rela-tionships with each other and with parts outside of themodule—this can be thought of as being the designrules of the module. In this instance, the modularity isperfect. In other cases, modules will be similar ratherthan identical. In this case, representing them as mod-ules implies either that the module must be overspeci-fied (in order to achieve all the functions) or that theperformance will suffer (where only functionality pre-sent in all clusters is included in the standard moduledesign). We term this imperfect modularization, whichit is a feature of many designs that use modules asplatforms that are then tailored.

The design rules governing modules SS and TT aredifferent from those governing the bus module. Thevalue orientation of the conceptual architectural dia-gram has still not been specified as the DSM denotessymmetrical relationships between chunks. However,in the absence of asymmetry the bus would tend to bemore important as its design rules have a greater visi-bility than those of the modules SS and TT.

4.2. Asymmetry

There are occasions where asymmetric physical do-main relationships occur as illustrated by the example

in Figure 6, where the modular bus VV is more depend-ent on the modules SS, TT, and UU than the reverse.Where this is the case, pictorial conventions becomemore important in indicating the value gradient, and itis necessary to explicitly denote the direction of controlto avoid ambiguity.

What do arrows or orientation denote about depend-ency in Figure 6? The bus module VV is dependent onall other modules and not the reverse. Therefore, in thisinstance, the arrows flow from the power source to thesink, and the orientation is with the higher value rela-tionships at the bottom and not the top.

4.3. Further Concepts: Pinning andHolding Away—Imperfection

Many architectures are more complicated than the ex-amples inspected above. Figure 7 shows many possi-bilities. Either (A, B) and (C, D) can be concatenatedinto modules, the sequence A through F be thought ofas one super module, an intermediate module TT besandwiched between module SS (comprising A, B) andmodule UU (comprising E, F), or simply described asbeing comprised of the primitives A through F with thebus module.

This example also illustrates the notions of “pin-ning” and “holding away.” Here B is pinned in placebetween A and C by its relationship with A and C. Thisis a common and easily appreciated situation in muchphysical architecture. A less easily appreciated situationis that of “holding away,” which is seen here in thatelement A is held away from element C by element B.The combination of these two notions assists in describ-ing the drawbacks of various clustering arrangementsand clustering heuristics. Pinning can only occur tocompound elements (modules) that have relationshipswith two modules, while any primitive element can beheld away.

4.4. Auxiliary, Weak, or Subsidiary Buses

It is possible that elements within a module are pinnedin place in the center of a sequence, or are primitives

Figure 4. Simple bus, four chunks, no modules.

7Note that buses may also be comprised of multiple primitiveelements, in which case they may be referred to as a “bus module.”


Figure 5. Simple bus, four chunks, two modules.

Figure 6. Multiple bus; six chunks of three modules.

Figure 7. Imperfection, pinning and holding away.


held away from the main bus by a sequence that ispinned to the main bus, yet have buslike characteristics.If this is the case, the clustering algorithm will be forcedto make a choice between disrupting modules adjacentto the main bus or forgoing the clustering opportunity.In the latter situation weak buses occur—computerscience literature occasionally refers to the concept ofan auxiliary bus or subsidiary bus, which is why thealternative descriptions are noted.

This concept is illustrated in Figure 8, where theprimitive element D is pinned firmly in place in themiddle of a sequence yet has weak relationships withmuch of the system. In the absence of the strong pins tothe adjacent elements, the weak system-wide relation-ships would cause it naturally to be incorporated intothe main bus; however, this migration cannot take place,and so the weak bus remains stranded. In a real worldsystem this would represent an element whose designhas not only to take into account the upstream anddownstream relationships with C and E, and the busUU, but which also has to reach an accommodationwith A, B, and F. Unsurprisingly, any designer or main-tainer of such an element will find it difficult to keeptrack of and optimize all the possible causes and effects.This difficulty in visualizing the problem space is evi-dent in the various unsatisfactory conceptual architec-tural diagrams on the right of Figure 8.

In some respect, auxiliary buses arise because the“busness” of the element is less strong than either themodularity of the element (if it is pinned in a module),or the modularity of the elements that are holding itaway. Thus the notional objective function is being

asked to choose between two undesirable options—dis-rupt a module or force a bus out into an auxiliarybus—is guided in its choice by a comparison betweenthe degree of perfection of the outcome. The choice willoften also be path-dependent, if a nonexhaustive searchis conducted, as the relative goodness of the choices willbe determined by prior choices that have chosen toemphasize one alternative over another.

4.5. Clustering and Multiple Dimensions

A problem with applying automated clustering algo-rithms to some complex DSMs is that they find it veryhard to extract the relevant information from the data,and then to convey it to the user. This is most obviousin poor handling of pinned modules, buses, and path-dependent situations. We investigate this further in therest of this section.

4.5.1. Path Dependency in ClusteringConsider a triangular arrangement of symmetrical rela-tionships that can be loosely clustered into three similarmodules AA, BB, and CC, as shown in Figure 9. TheDSM for this can only ever show one of the real clustersand must progressively break up the second and third.The way in which the clustering algorithm operates willbe path-dependent inasmuch as once it has started tocluster on any nodes it is unlikely to ever reverse out toa different configuration. This situation may occur be-cause of the way in which raw data is presented to theclustering algorithm (for example, branch and boundalgorithms that are presented with a partially clusteredstarting point may never branch widely enough to

Figure 8. Auxiliary or weak or subsidiary buses.


evaluate alternative solutions) or may arise throughchance if a perfectly random starting point is presentedto an algorithm that makes an initial random guess. Inthe example below, cluster CC has been largely brokenup even though it is identical in all respects to the othertwo clusters.

This path dependency situation arises because of ascarcity of dimensions. It is simply difficult to representthe two dimensional triangle in the one-dimensionalspace of a DSM.8 Theoretically, one could cluster inmultiple dimensions (while still remaining within thephysical domain), and there may be merit in examiningthe possibilities this offers. A more important practicalpoint in the short term is to test algorithms for oversta-bility as one would prefer algorithms that search widelyfor optimal clustering solutions yet are robust.

4.5.2. Dimensions and TopologyIn the planar triangular cluster AA, BB, CC that we sawabove there is a simple and clear structure. The equiva-lent DSM is able to map the AA-BB clusters in a waythat is easily interpretable. As previously mentioned,the manner in which this is clustered (interpreted) in aDSM will depend on the extent to which the clusteringalgorithm is path dependent. It could as easily have beenAA or BB clusters that were broken up by being posi-tioned where CC is.

This is relevant because normally the DSM is whatis used to interpret the underlying structure. The correctquestion to ask is: “If one is only aware of the infor-mation within the DSM, can one see what the realstructure of the thing is?” as, otherwise, one may makeerroneous simplifications or introduce false complex-

ity. So, in this example the real structure might falselybe interpreted as being two heavy modules and a lightmodule, and it could simply be chance that determineswhich is perceived as being the lightweight module. Inplanar rings it seems reasonable that the clear simplestructure could be seen by inspection, so let us turn tomore interesting examples.

The simplest three-dimensional structure is a tetra-hedron or 3-dimensional pyramid, depicted in Figure10 showing four equal clusters, each with dense internalrelationships and weaker (or sparser) external relation-ships.

As before, if all the clusters are perfectly equal, it ispurely a matter of chance how any clustering algorithmwould present an answer. In the example shown below,cluster DD is the one that is visually disrupted most bybeing presented last in the sequence. This has the effectof spreading its intercluster relationships over a widerspatial area, which is depicted in the macro-scale DSMas being lower density blocks of grey. To an untrainedobserver this might be thought to be a bus structurewhere cluster DD is the unique possessor of systemwide integrating functions and some semirandomcrosslinking occurs in the zone AA-CC.

Indeed, it is only with knowledge of exactly what theroles of the elements are in each cluster that a humanwould have been able to intuit that DD should be thebus as opposed to any other cluster. Often this intuitionwill have been right, but if there is any dynamicism inthe architecture, one can easily see how historical valuejudgments as to what is more or less important can beprone to rapid disruption as a new entrant (with a newperspective) realizes the dislocating impact of anycreeping changes in underlying structure. In these situ-ations, the value judgments inherent in assigning aparticular grouping to the “bus” become a historicalliability.

Given the importance of reducing complexity andminimizing artificial boundaries in an architecture (ir-

Figure 9. Planar triangular clusters.

8In order to best illustrate this point, the extreme form ofclustering with exclusive assignment of elements to sets (modularclusters) has been used. The point remains valid, albeit to a lesserextent if nonexclusive assignment is employed and it then becomesdependent on the notional costs and benefits associated with bounda-ries as well as random issues associated with path dependency.


respective of domain), it is somewhat surprising that sofew architectural diagrams (e.g., hierarchical productdecompositions or organization diagrams) use anythingother than planar representations. This tetrahedron is aperfectly simple elegant little structure when perceivedin three dimensions, yet is terribly complicated whenseen in only two.

4.6. Molecular Diagrams

The detailed interpretation of the DSM itself and thedrawing of cartoon hierarchies are adequate for micro-level description; however, large DSMs representingnonplanar architectures can be difficult to intuit. Analternative is something we term a 3-dimensional mo-lecular diagram.

A molecular diagram is akin to the cartoon hierar-chies inasmuch as it is a pictorial network. However,cartoon hierarchies become swamped in large-scalenetworks, and so we choose to condense multiplehighly related elements together. The size of the resul-tant molecule is then representative of the size of thecomponent elements. The intermolecular arcs representvisibility in such a network. If computation allows, it ispossible for the density of the molecules to representthe interelement visibility within the molecule.

How one selects which elements to condense intowhich molecules is up to the user. For our purposes we

have typically used clustering algorithms and/or man-ual clustering guided by our micro-level understandingof problems with clustering. However, other users mayhave other needs. In the molecular diagram, elementsand arcs that fall beneath threshold criteria may beomitted for clarity.

Such molecular diagrams are a natural outgrowth ofcartoon hierarchical drawings. They provide an inter-mediate level of abstraction between cartoon hierar-chies and visibility-dependency plots (which will bediscussed next), which we have found useful in visual-izing the structure of large-scale complex architectures.Ideally a molecular diagram should have clear defini-tions for the meaning of the size of the various pictorialelements (e.g., molecule size; molecule color and den-sity; arc weight and arrow head conventions), but untilnow we have found it adequate to use our judgment.9

Some examples of very simple molecular diagramswere introduced from Figure 9 onwards in the descrip-tion of path dependency issues. These were used toillustrate points regarding hypothetical architectureswithout needing to include irrelevant and potentiallymisleading detail. In Section 6, the molecular diagram

Figure 10. Tetrahedron of clusters.

9This is an area where further research is likely to be fruitful;especially, in order to automate the generation of molecular diagramsfor large and complex systems. One such tool that allows the genera-tion of 3D UML diagrams is WilmaScope software, which can bedownloaded for free from http://www.wilmascope.org/.


of a typical real complex product is developed illustrat-ing the typical level of detail that a molecular diagrammight show.

We wish to emphasize that molecular diagrams arenot yet as highly developed as either DSMs or visibil-ity-dependency plots. There are many variables thatcontrol their presentation, and, as yet, no agreement onwhich variables are most important and what should bethe typical settings. As such, molecular diagrams are avery immature area that we are introducing for the firsttime.10

5. DESIGN HIERARCHIES; VISIBILITYAND DEPENDENCY

Baldwin and Clark [2000] take the stance that formodularization to work in practice, architects mustpartition design parameters into two categories: visibleinformation and hidden information. Only visible infor-mation may interact outside a module, and so a goodmodular design will contain interface specificationsthat serve to decouple hidden information from visibleinformation to allow designers the maximum flexibil-ity.

The relationship between hidden and visible infor-mation can be represented in a design hierarchy [Bald-win and Clark, 2000]. The left side of Figure 11represents an example of a design hierarchy, and theright side depicts the equivalent DSM representation.In this example, there are three levels of visibility:global design rules (at the top); locally visible interme-diate level design rules (interface rules in this example);and intramodule design rules (at the bottom of thehierarchy).

With a three-level hierarchy, a design rule may bedirectly visible to a module below it (i.e., a line linksthe two boxes) or indirectly visible via an intermediatelevel rule. In this example, the global rules are visibleto all of the system, each set of interface rules is visibleto 3/7 of the system, and each set of module rules isvisible to 1/7 of the system. This approach to visibilityis, of course, only valid while the system is a nestedhierarchy where information (or design rules) onlyflows downwards. In order for this to be achievable thesystem level design rules must be—for all practicalpurposes—scale-independent. If such a nested hierar-chy exists, only one element may be at the apex.

5.1. Visibility Calculation

In this section we describe what visibility is and how tocalculate it by introducing simple binary hierarchicalsystems first. Then, we consider nonbinary and non-hierarchical systems, refining the calculation processand creating more precise definitions of visibility anddependency as necessary.11

To calculate visibility for any element in a system,we need to ask, “What other elements would need to beredesigned if this element changed?” So in the systemof Figure 12, a change in element A will directly haveconsequences for elements B and D, and indirectly haveconsequences for elements C and E. However, a changein element B only has consequences for element C andnot for A, D, or E. If we make the assumption that B is100% dependent on A for its design parameters (andlikewise all other links are set as 100%—an assumptionwe will later vary), then by inspection we can say thatA is visible to 100% of the system.

Figure 11. Three-level design hierarchy [adapted from Baldwin and Clark, 2000].

11It is worth noting that our calculation of visibility is differentthan those introduced by Baldwin and Clark [2000] despite the factwe use the same notion. While their calculations allow for onlyhierarchical structures, ours include both hierarchical and nonhierar-chical.

10There is evidence to suggest that 3-dimensional repre-sentations of connected graphs have advantages in conveying soft-ware products architecture to users over 2-dimensional graphrepresentations [Dwyer, 2001].


When discussing “visibility to the system,” thereare two different definitions of “the system”: the systemexclusive of the element in question; or the systeminclusive 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 systemexclusive of itself (i.e., is visible to 1 of 4 elements).12

In practice, it normally does not greatly matter which isused for characterization purposes provided that thesystem is sufficiently large.

If the strength of the link is taken to denote theprobability of a redesign of the dependent elementbeing necessary given that a change has occurred in thefeeding element, then it is possible to analyze morecomplex architectures. The system of Figure 12 can berepresented by the leftmost DSM of Figure 13.13 Thenthe reachability matrix [Warfield, 1973] gives us thenumbers of steps that any one element can be reachedfrom another in a network. In its simplest form, it is theinitial DSM raised to successively higher powers asshown in the central DSMs of Figure 13 for the samesystem.

For example, in this figure the circled cell in thesquare of the initial DSM shows us that element E canbe reached from element A in two steps and that thepathway taken has a 100% total probability of causingredesign. Note that the cube of the initial DSM is notpopulated, indicating there are a maximum of two stepspossible in this system. Lastly, by summing across thearrays we populate a summation DSM at the right ofFigure 13 in which each cell represents the probabilityof an element affecting another element by all thepossible routes. The sum of the columns then revealsthe impact of each element on the total system. Sincethe initial DSM does not include any element’s influ-ence on itself the column sums are the exclusive visi-

bility, which can be easily converted into percentageformat.

It is possible for this computation to yield impossibleresults for systems that are not perfectly hierarchical.An example of this is shown in Figure 14, where ele-ment B is now also connected to element E with all otherconnections as before. In addition, we have includedprobabilities that are less than one that read, for exam-ple, as follows: “There is 70% probability that a changein element A results in a redesign of element B.”

The initial matrix is fine as it stands, but whensquared it yields a sum of 1.7 in cell A-E as shown inFigure 15. This would suggest that the design of ele-ment E is 170% probable to change if a change hasoccurred in element A. This situation arises because ofthe two different pathways from element A to E, eachof length 2. Clearly a 170% probability is impossible,as by definition the maximum probability can only be100%.

In this instance it is easy to make the ad-hoc decisionto truncate this cell to 100% as there exists a pathwayfrom A to E via D of 100% probability, and such atruncation is shown circled in the figure. A more inter-esting case would arise if the A-D-E pathway hadyielded a probability of less than 100%—say 90%. Inthis case, ought we truncate to 100%, or to 90%, or tosome other number? This question arises because theDSM is a high-level abstraction of the underlying sys-tem—the DSM of the underlying system would bemuch more detailed and actually link together the de-sign parameters in play with much less ambiguity. Theissue is what information is being transmitted along thepath A-B-E or A-D-E as: If it is the same information,then the maximum change should be 90%, whereas ifit is different information, then the maximum changemight be another amount. Clearly since “a change hasoccurred” in A the information being broadcast is om-nidirectional and so the crux becomes to what extent theinformation is modified by B as opposed to D. We takethe stance that each branch that crosslinks will alwaysretain whatever is the most important aspect of thechange in A for all downstream elements, and so theessentially subtractive process of losing information(reducing visibility) is a context independent one oflosing the least important information first.14 Therefore,

Figure 12. Binary hierarchical system.

12Throughout this paper we make the simplifying assumptionthat all elements are of equal size when calculating the size of thesystem, and therefore visibility within the system. 13In this DSM there are four cells with 1.0 entered in them andwhich refer to the four arcs (A-B, B-C, A-D, and D-E) indicating foreach arc a 100% probability of redesign given that a change hasoccurred.

14The decision to use this definition is only justifiable becausethe DSM is an intermediate level abstraction intended to assist ininterpreting architectures, or in a priori optimization of architecturesat an early stage of the design process. For interpretation purposessince any abstraction implies a loss of detail, this is essentially atradeoff that must be desirable to obtain a better feel for the overallarchitecture. For design purposes it is probable that the highly detailedparameterization required to use any other definition would requireso much study that it would not be possible to consider the full rangeof possible architectures.


the correct truncation would be to 90%, or in general tothe maximum of the alternative pathways of that length.

This definition of how information is lost in a con-text-independent manner also affects our hitherto naïvedecision to sum across the successive powers of thereachability matrix in order to populate the summationmatrix. Instead, in the same way that we truncate mul-tiple pathways of the same length to the maximum ofthe alternative pathways, so too is it necessary to trun-cate multiple pathways of any length to the maximumof the alternative pathways.

This leads to a final and precise definition of visibil-ity as “the extent to which a change in any one element’sdesign information affects any other element by theclearest possible (single) path irrespective of length,and making the assumption that information is lost inthe order of least important first irrespective of con-text.” With this revised definition the computation ofvisibility and the companion concept of dependencybecomes a mechanistic chore.

5.2. Interpreting Architectures UsingScatter Plots of Visibility-Dependence

The architecture of a system yields a visibility-depend-ency signature that is best appreciated as a scatter plot.This signature can be described by five generic charac-teristics: homogeneity, connectivity, layering, relation-ship laterality, and decompositional cleanliness. Thesecharacteristics are illustrated in the six examples ofFigure 16 and qualitatively discussed below.

Homogeneity: The degree of scatter or dispersionin the data points illustrates the degree of homogeneityor heterogeneity in the system. In assessing homogene-ity, one needs to exercise caution, as identical data willonly show as one point. A homogenous system is onewhere all elements are equally linked—these are “neu-tral” architectures; i.e., it is difficult for a subset ofelements to dominate the system. Homogenous systemswill therefore tend to be closed topologies—such as 2-or 3-dimensional ring/sphere structures.

Connectivity: Not all networks are equally con-nected, and this is observable by the location of thecenter of gravity of the scatterplot. The closer the centerof gravity is to the origin, the lower the degree ofconnectivity.

Layering: Multiple tightly clustered groups or hori-zontal lines indicate that a layered structure exists.Depending on the degree of connectiveness and topol-ogy, this may be layer-cake decomposition or a concen-tric spherical decomposition. Layering easesmodularization. The topmost layer may only be repre-sented by one data point, and often the number of datapoints grows as one descends. If the scatter plot consistsof clustered groups, then it indicates that within eachlayer there is a common amount of crosslinkingwhereas horizontal lines suggest heterogeneity incrosslinking. If the DSM has been constructed at a givenlevel of decomposition, and not had high-level ruleelements added in, these upper rule layers might not berepresented, even though they do exist. These wouldrepresent assumptions that are so basic that they are not

Figure 13. The reachability matrix of a DSM.

Figure 14. Imperfectly hierarchical system (crosslinked).


even mentioned. Such situations typically exist whenthere is a great deal of agreement about what is thedominant design and/or where intangible relationshipshave not been inserted into a physical domain derivedDSM. This is discussed further in Section 5.4.

Decompositional Cleanliness: If relatively unilat-eral relationships dominate the system, then the systemoffers the potential to be decomposed into a cleanhierarchical structure with little crosslinking. Assumingoptimal decomposition, the steeper the (negative) gra-

Figure 15. Reachability matrix of crosslinked system.

Figure 16. Characteristic types of visibility-dependence signatures.


dient of the trend line, the less crosslinking there is. Thisis because clean decompositions have few relationshipsthat cross the decomposition boundaries, and so thevisibility of a given element is minimized. This leads toa general caution regarding interpreting the scatterchart, as it is a combination of the intrinsic architectureof the system and the decomposition that has beenapplied. The exception to this caveat is that where asystem has been fully decomposed it can only reveal thesystem architecture.

Unilateral and Bilateral Relationships: The extentto which the network has one-way unilateral relation-ships as opposed to bilateral relationships will deter-mine the slope of the trend line in the data. This isbecause bilateral relationships are essentially “demo-cratic”—the more an element is visible, the more it isdependent, while unilateral relationships lie along theorthogonal trend line. Conversely, the slope of the trendline is a quantifiable measure of the degree of bilateralversus unilateral relationships in a system. Unilateralsystems can always be resequenced to force relation-ships below the diagonal, while for a bilateral systemthis is not possible as the DSM will be symmetric aboutthe diagonal.

5.3. Mapping Physical DSMs to Task DSMsTo Obtain Probabilities

The simple binary relationship marks in many processdomain (i.e., task) DSMs skirt the issue of what is beingrelated between elements, and it is often unreasonableto drill to the level of detail required to fully populate aparameter DSM. While there are examples of populat-ing task DSMs with rework probabilities [Browningand Eppinger, 2002], we suggest that the physical do-main DSM is more useful in characterizing productarchitectures. This is because most process DSMs onlyreveal the design process in use—it is likely to havebeen constructed by asking the designers how theyactually design the system rather than by asking themhow else they might design the system. Consequently,the ability of process DSMs to describe product archi-tectures is somewhat constrained (or biased) by onlyhaving information regarding the design process inuse.15

In contrast, the physical domain DSM is populatedby asking how elements relate to each other in thearchitecture (regardless of the design process in use),and there is normally a far greater understanding of all

the physical dependencies. So, a given product mayhave many above-diagonal marks in its physical do-main DSM while the process domain DSM has beenreduced to a manageable linear process with relativelyfew above-diagonal marks representing a few designiterations. Similarly, the process domain DSMs tend tobe binary, and direct assessment of rework probabilitiesis difficult and unintuitive, while it is relatively easy forrespondents to identify with weightings in a physicaldomain. These weightings (typically on a four-pointscale as in Table III) can then be mapped to reworkprobabilities and become an indication of the processarchitecture, unsullied by the imposition of design as-sumptions that reduce the probability of rework.16

5.4. Representation of IntangibleRules/Relationships

Baldwin and Clark [2000] propose that a modular de-sign process has three stages: (1) formulation of designrules, (2) parallel work on modules, and (3) testing andintegration. The stage-1 relationships control elementsof the design process such as the size, the configuration,the schedule, manufacturing location, etc. The stage-3relationships control the testing and integration of thedesign. From this proposition it can be seen that thestage-2 relationships are equivalent to those consideredin the standard physical domain DSM. However, inorder to consider the entire signature of a productarchitecture, the elements representing intangible re-lationships need to be inserted; we refer to them asstages 1 and 3 of the design process. As an example,while the analysis of a physical 10 MWe generator willreveal all stage-2 relationships and their associatedtasks, it may not be possible to directly intuit that theunit had to be tested (a stage-3 task relationship) or thatthere was the task of deciding what power generatorought to be designed (a stage-1 task relationship).

6. CASE STUDY—GAS TURBINEGENERATOR SET

A synthetic physical DSM for a generic 10 MWe gasturbine driven electrical generator set was constructedby decomposing it into 31 subsystems. The subsystemsinitially were listed arbitrarily in the DSM, and then tickmarks denoting material relationship from one subsys-

15Caveat: Some distributed approaches to process modelingyield models based on the fundamental information needs of smalltasks and illuminate numerous alternative approaches to design[Browning and Eppinger, 2002]. We would like to thank one of theanonymous referees for pointing this out.

16In this paper, we map Table III dependency strengths torework probabilities as follows: 0 dependency strength correspondsto 0% rework probability, 1 dependency corresponds to 30% rework,2 dependency corresponds to 60% rework, and 3 dependency corre-sponds to 90% rework. This mapping is consistent with other DSMresearch as described by Smith and Eppinger [1997].


tem to another were inserted.17 At first, these relation-ships were noted on a binary scale of 0 (no dependencyexists) or 1 (a dependency exists). Next, an explicitassignment of the relationship strength was performed,where the tick marks were replaced with a four-pointscale in accordance with Table III. The resultant DSMis shown in Figure 17. It can be seen from the figure thatthe gas turbine generator set is not a fully integratedproduct because the matrix is not fully populated.Therefore, it ought to be possible to manipulate theDSM to force as many relationships as possible closeto the diagonal and thereby expose the irreducible clus-ters 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 ofsystem-wide relationships is emphasized over “good”clusters. Figure 17 shows a manually clustered DSMwith clusters arbitrarily marked off by borders to em-phasize their location and nominal boundaries. Afterinspection of the clusters, they were given names toidentify them. Notice how clusters can overlap (e.g.,

turbine island with the core)—in extreme cases they canbecome completely embedded.

The identification of a cluster of system wide ele-ments that spans the bottom, or the right-hand side, orboth, is characteristic of these sorts of DSMs. In thefunctional (i.e., task) domain, such a system wide layerwould normally equate to the test and integrate tasksthat are performed towards the end of a project se-quence. In the physical domain there is no timelineassociated with being in the lower right-hand corner,and so it is better to term this a “bus.” This bus is actuallytermed the “main bus” as system-wide integrating ele-ments need not necessarily be confined to this lowerright area. For example, a weak bus is identified by thedashed ellipse in Figure 17. Consider also how easy itis to give exactly the same cluster a different yet equallymeaningful name, and how easy it is to identify differ-ent cluster boundaries. This demonstrates the dangersof manual intervention and motivates the need for someform of automated clustering algorithms. However, be-fore delving further into automated clustering algo-rithms, it is worth stepping back and reflecting on thefeatures seen so far. This allows clarification of theterminology so as to have a firm foundation for the nextstep.

Figure 17. Physical DSM of gas turbine with manual clusters.

17See Sharman [2002] for further details of the DSM genera-tion.


6.2. Comparison with Real Architectures

By inspecting the gas turbine we can observe if thefeatures proposed in Section 4 are in fact present. Theprocess of identifying potential features improves ourunderstanding and allows us to recluster the gas turbineDSM in an improved manner.

The DSM shown in Figure 17 exhibits weightedstrength asymmetric relationships, and this is most evi-dent in the manner in which the bus module is popu-lated. The below diagonal portion of the bus module ismore heavily populated (both when looking at the sim-ple binary existence of relationships and when lookingat the strengths of the relationships) than the abovediagonal portion of the bus module. Under the conven-tion in use this asymmetry indicates that this busmodule is relatively dependent on the remainder of thegas turbine system rather than the system being depend-ent on it.

Furthermore, a sequence of five nonbus modularclusters is identifiable. In this diagram they are givenidentifying names: heat and noise; turbine island; core;

air clean-up; electrical. The features discussed in thecartoons are now observable: All but the individualelements are pinned together and one is pinned to themain bus module. The pinned heat and noise moduleexhibits an auxiliary bus characteristic (outlined bythe dashed oval) but is apparently held away from themain bus module by the pinned electrical module.Some of these modules are relatively more populated(perfect) than others, have different sizes, and exhibitvarying degrees of asymmetry.

6.3. Applying Dimensionality to the GasTurbine

It is valid to enquire whether this is the best clusteringarrangement, and, by considering the notion of dimen-sionality, it can be shown by inspection that the im-proved solution is better even in the absence of acodified value system. Exploiting the torosity of theDSM yields the better manual solution of Figure 18.This is “better by inspection” as it changes no sequenceswithin modules but simply adjusts the sequence of some

Figure 18. Better manually clustered DSM.


of the primitives in the bus module to allow the un-pinned electrical module to nestle against the bus mod-ule. This obviously reduces the size of any notionalpenalty term associated with the relationships denotedby the auxiliary bus being held away from the main bus.

First, this alternative solution illustrates the impor-tant point that in the physical domain there is no reasonwhy a bus is best parked in the lower right or upper leftcorners. Inspection of the literature shows that, irre-spective of domain, these are the normal parking loca-tions, and it appears that this is a carryover from processdomain DSMs where there is good reason to prefer thislayout. Exploitation of this parking freedom is possibleonce dimensionality is understood. Second, it may stillbe valid to use the normal parking convention if thenumber and arrangement of modules permits it. This isbecause it is easiest to inspect, and because the physicaldomain often maps closely to the task domain so arrang-ing it in this way eases the process of comparison. Thispoint is expanded upon by Sharman, Yassine, and Car-lile [2002], regarding interdomain mapping. Third,many runs of the Thebeau clustering algorithms failedto reveal this clustering solution. This suggests that theunderlying clustering heuristics are less rich than theproblems to which they are being applied and that, todevelop better clustering algorithms and metrics, it isnecessary to fully understand the principles of cluster-ing and the language of representation.

6.4. Expanding the DSM To IncludeStage-1 and -3 Relationships

Until now, to keep the analysis simple, the gas turbine’sDSM has represented the relationships between onlythe 31 tangible (physical) elements, representing stage2 of the design process. However, as mentioned inSection 5.4, we need to insert the elements and relation-ships that represent intangible relationships (i.e., stages1 and 3) in order to consider the entire signature of aproduct architecture. This insertion process is generallydescribed in Baldwin and Clark [2000]. However, anelaborate explanation of the insertion procedure for thegas turbine can be found in Sharman [2002].

The insertion of stages 1 and 3 resulted in 14 newelements introduced into the DSM. Eleven of these newelements represent the stage-1 tasks of formulating thedesign rules, and these are placed first in the sequence,and three represent the stage-3 elements of testing andintegrating and are placed last in the sequence. These14 elements are our interpretation of the missing ele-ments of the design process of a generic generator settogether with our interpretation of the overall relation-ships. Stage-1 elements comprise three major steps:determine scale of product, apply scale dependent rules

to determine decomposition, and apply decompositiondependent rules to determine module design rules.Stage-3 elements are: component, assembly, and fulltests. After the insertion of stages 1 and 3, the DSM willbe represented by its expanded 45-element version asshown in Figure 19.

6.5. Gas Turbine Molecular Diagram

In an attempt to represent the architecture in a moreintuitive manner a molecular diagram was created. Theobvious clusters were manually identified in the DSM,as far as possible based on Figures 17, 18, and 19, butwithout overlaps (i.e., unpinned) to ease the task ofcomputing relationships.18 Then, in order to get a feelfor molecule size and connectivity, the summed inter-cluster relationships are shown in the collapsed 18-ele-ment DSM of Figure 20.

Ignoring the singletons, it is then possible to sketchout a “molecular” hierarchy diagram of the gas turbinewhere circle size indicates the sum of the hidden rela-tionships (i.e., the on-axis score), and line size andarrow size indicate direction and strength of visiblerelationships as shown in Figure 21.

The closed 3-dimensional form of this moleculardiagram illustrates why the DSM clustering algorithmsfind it difficult to get traction, and why planar hierar-chical “organization diagrams” are insufficiently richrepresentations. This naïve molecular diagram is suffi-ciently simple to use as a visual representation whendiscussing the results of this analysis, yet not so simpleas to misrepresent the complexity of the underlyingstructure. As such, it is a meaningful aid for determiningarchitectural decomposition with people who do notunderstand the actual product complexity, and whomight desire to impose counterproductive artificiallysimple solutions that would impair the inherent archi-tectural value. For these purposes this molecular dia-gram is an improvement over the DSM representationof Figures 17 and 18, which can easily be misinter-preted as Figure 3 illustrated and has now been shownin this case. Nevertheless, the DSM is still required sothat the technical expert can create the correct molecu-lar diagram to use as a communications tool to illustratethe issues to the nonexpert.

18A short example describes how Figure 20 was generated fromFigure 19, and how this then gives rise to the molecular diagram ofFigure 21. The four elements in the upper left of Figure 19 are allassociated with determining the scale of the product (i.e., stage 1a),and all relationships are populated with a weighting of 2. Thus thecorresponding 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 sizeof a molecule (e.g., “24”—written in the circle) or the strength of alink (e.g., “21”—not written in the arrow) in Figure 21.


6.6. Gas Turbine System Signature andArchitectural Hierarchy Diagram

Calculating visibility revealed the architectural signa-ture of the scatter plot of visibility-dependency shownin Figure 22.19 Bearing in mind the characteristicsdiscussed in the previous section, this signature may becategorized as shown in Table IV.

The seven elements having dependencies of ~5–10% (Group A in Fig. 22) are all associated with designtasks that occur prior to generating preliminary de-signs,20 while all other elements have dependencies of

~40–70% (Group B in Fig. 22). Thus these seven tasksseem to have an order of magnitude greater leverage inthe design process than almost anything else.

In this system performance will greatly depend onthe extent to which the human designers are able to apriori determine the optimal system decomposition anddesign points (by defining the correct element andinter-element feedback parameters) prior to their emer-gence in linked models and full scale testing. Moresimply, the performance of the design process, and theperformance of the resultant gas turbine, are highlydependent upon the designers choosing the parametersof Group A wisely on their first pass. Once the resultantparameters have cascaded into Group B, it becomesdifficult to change any one parameter without having ashower of undesired knock-on effects to other parame-ters.

Figure 19. Expanded gas turbine DSM including stages 1 and 3.

19This 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 highlysensitive to the probability and topology of any feedback loops. 20They are the identification of the power rating, the loadmarket (peaking, base load, etc.), other customer requirements, cycleselection, time to market, trade studies, and configuration.


Figure 21. Molecular hierarchy diagram for gas turbine.

Figure 20. Collapsed 18-element DSM from the 45-element version.


This paper only addresses characterization and rep-resentation and is not primarily intended to discussanalysis; however, each representation has differentdrawbacks for analysis. An example of this is that whilethe scatter plot gives an indication of an element’simportance, it does not give an indication of the path-way by which the element affects others. So, inspectionof the V-D scatter plot does not reveal that the elementsof Group A are strongly linked to those of Group B2(which are the core of the gas generator) and lessdirectly, but similarly strongly to those of Group B1(primarily verification and validation) and that this isan important way of directly and indirectly influencingthe performance of the system as a whole. Instead it isnecessary to turn to the original DSM or the moleculardiagram to see these links.

In the visibility-dependency scatter plot three linesare shown: the 1:1 slope, and the linear and quadratictrend lines. Analysis based on points’ position com-pared to these trend lines is superficial; however, theydo give a quick indication of which are the absolutelyand relatively important nodes in the architecture.

It is interesting to note that more simplistic repre-sentations and/or analysis underestimate both the ho-mogeneity of coupling and the extent of the coupling inthe generator set. Thus it would have been easy tounderestimate how easily change propagates through-

out the structure irrespective of what is the initiatingelement. In the case of this gas turbine the implicationis that beyond group A there are few easy fixes oropportunities for penalty free cost reduction as every-thing is highly connected.

7. CONCLUSION AND FURTHER WORK

In this paper, we have introduced the basic syntax andsemantics for scrutinizing a DSM in order to charac-terize the architecture of a complex system. We havealso demonstrated how simple building blocks (i.e.,DSM constructs) were helpful in analyzing the morecomplex architectures, such as that of the generator set.The paper demonstrated why it is difficult to arrive atautomated clustering algorithms without understandingthe implications of modularity and modularization interms of path dependencies and dimensionality. Byusing the concepts of visibility and dependency wewere able to describe the fundamental characteristics ofa range of architectures that span the continuum frommodular to integrated architectures in a unified quanti-fiable manner that allows for objective functions to bebuilt on a fundamentally sound basis. We also were ableto show how multidimensional molecular diagrams canbe drawn from DSMs, to serve as an intermediate levelof abstraction that shields the nonexpert from the details

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 togetherwith the program for performing the visibility-dependency calculations.


whilst still giving them sufficient information to be ableto participate meaningfully. Each of these techniqueshas advantages and disadvantages as outlined in TableV. Ultimately each of these techniques merely attemptsto represent the same underlying reality, and each givesup some information in order to better convey otherinformation.

There are several limitations intrinsic to this ap-proach, each of which is based on either an assumptionor a simplification. First, it does not drill to the parame-ter level of detail. Therefore, there is an implicit as-sumption that all parameters are, to some extent,additive in calculating gross visibilities. Second, theconversion of relationship strengths to probabilitiesgreatly simplifies the parameter level situation. Third,the population of the full stage-1, -2, and -3 DSMassumes that stage-2 product (i.e., physical) domainDSM is isomorphic with stage 2 task domain DSM.

The research currently being undertaken into pa-rameter-level interactions [e.g., Clarkson and Hamil-ton, 2000] will, in time, answer questions one and two.In order to explore the third assumption, take a givenproduct that has been designed by a given process andexplore what alternative processes might have beenpossible, and compare the resulting signatures witheach other, and with the intrinsic signature.

Within characterization the natural extensions are tocreate quantitative metrics (such as average connectiv-ity—the mean of visibility and dependency; homoge-neity—the standard deviation around the averageconnectivity; laterality—the slope of the best-fit lineartrend line; layering—the number of discrete groups thatexist; ratio analysis of visibility:dependency21; etc.) andthen explore a library of existing product DSMsdatasets to observe what signatures exist “in the wild.”

Once a library of datasets has been characterized, themeta-level implications of the results should be evalu-ated. Another obvious extension of characterization isto automate the process of creating molecular diagramsand explore the sensitivity of the resultant diagrams totuning of the control parameters. Then conduct researchinto whether and to what degree users can usefullyincorporate molecular diagrams into their decision-making processes.

Extensions to this work fall into three classes: first,exploring the extent to which the limitations notedabove and the underlying assumptions are justified;second, looking in greater depth at the characterizationproblem itself; and, third, proceeding beyond charac-terization into analysis. Other extensions beyond thischaracterization work center on architectural optimiza-tion. Work to date [Baldwin and Clark, 2000] has em-phasized extreme modularity whereas this techniquemay allow integrated and semiintegrated architecturesto be analyzed. For example, for a given architectureexplore how societal value might be optimized and thenexplore to what extent intrinsically nonhierarchical ar-chitectures affect the optimization strategy for societalvalue. Following on from this, take an architecture thatis too large to be created by a single actor. For this,explore how actor value diverges from societal valueand how the resultant tension between societal valuecreation and actor value capture lead to pressures tomodify the product architecture. Explore how the pres-ence of multiple actors in multiple nodes leads to archi-tectural evolution in time as successive versions of the

Table IV. Characterization of the Gas Turbine Architectural Signature

21Trials with ratio analysis suggest that this may be a suitablemethod for differentiating fine differences between otherwise similararchitectures.


product are released and compare this with case studiesof architectural evolution.

REFERENCES

C. Alexander, Notes on the synthesis of form, Harvard Uni-versity Press, Boston, MA, 1964.

C.Y. Baldwin and K. Clark, Design rules: The power ofmodularity, MIT Press, Cambridge, MA, 2000.

T. Browning, Applying the design structure matrix to systemdecomposition and integration problems: A review andnew directions, IEEE Trans Eng Management 48(3)(2001) 292–306.

T. Browning, Process integration using the design structurematrix, Syst Eng 5(3) (2002), 180–193.

T. Browning and S.D. Eppinger, Modeling impacts of processarchitecture on cost and schedule risk in product develop-ment, IEEE Trans Eng Management 49(4) (2002), 428–442.

P. Clarkson and J. Hamilton, “Signposting,” a parameter-driven task-based model of the design process, Res EngDes 12 (2000), 18–38.

T. Dwyer, Three dimensional UML using force directed lay-out, Conf Res Practice Inform Technol, 2001, Vol. 9.

C. Fernandez, Integration analysis of product architecture tosupport effective team co-location, SM Thesis (SDM),Massachusetts Institute of Technology, Cambridge, MA,1998.

M. Fowler and K. Scott, UML distilled, Addison Wesley, NewYork, 2000.

J. Hartigan, Clustering algorithms, Wiley, New York, 1975.A. Kusiak, Engineering design: Products, processes and sys-

tems, Academic, San Diego, 1999.

A. Kusiak and C. Huang, Development of modular products,IEEE Trans Components, Packaging Manuf Technol PartA 19(4) (1996), 523–538.

R. Mantripragada and D. Whitney, The datum flow chain: Asystematic 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 high-tech products to mainstream customers, Harper Business,New York, 1999.

P. O’Conner, Practical reliability engineering, Wiley, Chich-ester, UK, 1991.

K. Otto and C. Wood, Product design: Techniques in reverseengineering and new product development, Prentice Hall,Upper Saddle River, NJ, 2001.

G. Pahl and W. Beitz, Engineering design: A systematicapproach, Springer-Verlag, New York, 1999.

T. Pimmler and S.D. Eppinger, Integration analysis of productdecompositions, DE-Vol. 68, Design Theory and Method-ology DTM 94, ASME, New York, 1994.

R. Sanchez and J. Mahoney, Modularity, flexibility, andknowledge management in product and organization de-sign, Strategic Management Journal 17 (1996), 63–76.

D. Sharman, Valuing architecture for strategic purposes, SMThesis (SDM), Massachusetts Institute of Technology,Cambridge, MA, 2002.

D. Sharman, A. Yassine, and P. Carlile, Architectural optimi-zation using real options theory and dependency structurematrices, Proc ASME 28th Des Automat Conf, DAC-34119, Montreal, Canada, 2002.

Z. Siddique and D. Rosen, Product platform design: A graphgrammar approach, Proc ASME Des Eng Tech Conf, LasVegas, NV, DETC99/DTM-8762, 1999.

Table V. Applicability of Each Technique


R. Smith and S.D. Eppinger, Identifying controlling featuresof engineering design iteration, Management Sci 43(3)(1997), 276–293.

M. Spinner, Improving project management skills and tech-niques, Prentice-Hall, Englewood Cliffs, NJ, 1989.

D. Steward, The design structure system: A method for man-aging the design of complex systems, IEEE Trans EngManagement 28 (1981), 71–74.

R. Thebeau, Knowledge management of system interfacesand interactions for product development processes, SMThesis (SDM), Massachusetts Institute of Technology,Cambridge, MA, 2001.

E. Tufte, Visual display of quantitative information, GraphicsPress, Cheshire, CT, 1983.

K. Ulrich and S.D. Eppinger, Product design and develop-ment, McGraw Hill, New York, 2000.

J. Warfield, Binary matrices in system modeling, IEEE Trans-actions on Systems, Man, and Cybernetics 3 (1973), 441-449.

D. Whitney, Why mechanical design cannot be like VLSIdesign, CTPID Working Paper, Massachusetts Institute ofTechnology, Cambridge, MA, 1996.

T. Yu, A. Yassine, and D. Goldberg, Genetic algorithm fordeveloping modular product architectures, Proc ASME15th Int Conf Des Theory Methodol, 2–6 September 2003,Chicago.

A. Zakarian and G. Rushton, Development of modular elec-trical 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 servedin ships and submarines worldwide. In 1991 he joined the Royal Dutch/Shell group, where he worked asa production engineer in the North Sea and Venezuela. After setting up Shell’s operations in Argentina hecompleted an MSc in Management & Engineering at MIT in 2002 and is interested in the design andoperation of complex systems, technology strategy, and the technical/commercial interface. He is aMember of the IEE and the IMechE, and has previously contributed papers to journals or conferenceproceedings of the SPE, ICAS, and ASME.

Ali Yassine is an Assistant Professor at the Department of General Engineering at the University of Illinoisat Urbana-Champaign (UIUC) and the director of the Product Development Research lab. He teaches agraduate class in Systems and Entrepreneurial Engineering and an undergraduate class in OperationsResearch. His research involves managing the development process of complex engineering systems,design process modeling, and IT-enabled concurrent engineering. Prior to joining UIUC, Professor Yassinewas 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 EngineeringDesign, IEEE Transactions on Engineering Management, Concurrent Engineering Research & Applica-tions (CERA), and several other international journals and conference proceedings. He also consulted onnumerous occasions for the automotive (Ford Motor Company) and telecommunications (Global One)industries in areas of decision analysis and product development management. Dr. Yassine received theB.E. degree in Mechanical Engineering in 1988 from the American University of Beirut. He received theM.S. and Ph.D. degrees in 1989 and 1994 in Industrial and Manufacturing Engineering from Wayne StateUniversity in Detroit, Michigan. He is a member of INFORMS, ASME, and PDMA.


Regular Paper Characterizing Complex Product Architecturesay11/Complex-Architecture.pdf ·...

Documents

Transcript of Regular Paper Characterizing Complex Product Architecturesay11/Complex-Architecture.pdf ·...